Now with 1.6. things get worse. The Hash object is not an JS object with added functionality anymore, its a wrapper around one.
The following code will work in 1.5.0.2 but not in 1.6:

test = $H({a: 1, b:2});
alert(test.a); // -> 1 in version 1.5

Instead, in prototype 1.6 you have to write test.get('a') to get to the property “a” of the underlying object. In case you need the whole object, there is always test.toObject() to the rescue. Bye bye, consise and short notation.

I feel the developers forgot what made prototype so wildly successfull: Its beautiful concept of enhancing the built in objects, not wrapping them.

I consider leaving the prototype world alltogether and will switch to mootools.

Unlike prototype, mootools returns a hash on filtering a hash.

Everything is up and running fine now.

They are a nice way to store flags, for example, and by providing an aggregate function to sum them up, one can easily compute complex unions of properties.

First we define an aggregate function to sum postgresql hstores, straightforward as this:

CREATE AGGREGATE sum(
  sfunc     = hs_concat,
  basetype  = hstore,
  stype     = hstore,
  initcond  = ''
);

Allows for beautiful constructs as

CREATE OR REPLACE FUNCTION array_to_hstore(text[]) RETURNS hstore AS $$
  DECLARE
    arr     text[];
    result  hstore;
  BEGIN
    SELECT INTO arr $1;
 
    SELECT INTO result sum(key=>1) FROM (
      select
        btrim(arr[idx.i]) as key
      from
        generate_series(1, array_upper(arr,1)) as idx(i)
    ) as dummy;
 
    RETURN result;
 
  END
$$ LANGUAGE plpgsql;

Now what can be done with that? For example we can turn comma separated lists into hstores:

mydb=> SELECT array_to_hstore(string_to_array('a, b, c, a', ','));
              array_to_hstore              
-------------------------------------------
 "a"=>"1", "b"=>"1", "c"=>"1"
(1 Zeile)

source /sw/bin/init.sh

$H({fruit:"apple", vegetable:"cucumber"}).reject(

  function(el) { return (el[1] == 'cucumber');}

) == $H({fruit:"apple"})

$H({fruit:"apple", vegetable:"cucumber"}).findAll(

  function(el) { return (el[1] == 'apple'); }

) == $H({fruit:"apple"}) 

Prototypes Enumerable mixin class does not properly respect the mixees internal format. For example the reject and findAll methods, operating on Hashes, return Arrays instead of Hashes.

var a = $H({a:1, b:2, c:1, d:3}); 
document.writeln(a.inspect().escapeHTML());
 
=>#<Hash:{'a': 1, 'b': 2, 'c': 1, 'd': 3}>
 
var b = a.reject(function(val){ return (val[1]==1) });
document.writeln(b.inspect().escapeHTML());
 
=> [['b', 2], ['d', 3]]   // !!! should be hash
 
var c = b.findAll(function(val){ return (val[0]=='d') });
document.writeln(c.inspect().escapeHTML());
 
=> [['b', 2], ['d', 3]]   // !!! should be hash

In Ruby (from which the inspiration for the Enumerable Mixin stems), the reject method does return a hash, not an array, when operating on an hash:

irb(main):001:0> a={:a => 1, :b => 2, :c => 1, :d => 3}  
 
=> {:b=>2, :c=>1, :a=>1, :d=>3}  
 
irb(main):002:0> b=a.reject{|k,v| v==1}
 
=> {:b=>2, :d=>3} 

The patch requires all classes that want to mixin Enumerable to define two more methods similar to _each:
_new, which returns an empty object of that class and
_add, that adds an element. Enumerable mixin thus needs to make no more assumptions about the internal structure of its mixee class.

After the fix the methods return correctly:

=> #<Hash:{'b': 2, 'd': 3}>