From: Markus <markus@...>
Date: 2004-09-06T12:47:31+09:00
Subject: Re: OK... :) question about hash and array literals

> Bill Guindon wrote:
> |Personally, I'd like it to remember the order you added things in, use
> |that ordering when iterating through the hash, and _optionally_ use it
> |for compares.

> Matz wrote:
> 
> Hmm, I thought hash order would be ignored always for compares.

I would think it would have to, if you don't want to break the semantics
of Hash.

> Matz wrote:
>
> Optional use of order is an interesting idea, although I want better
> looking API than
> 
> | {1=>2, 3=>4}.ordered != {3=>4, 1=>2}.ordered

If you make inspect (for example) respect the insertion order then you
have 

    {1=>2, 3=>4}.inspect != {3=>4, 1=>2}.inspect

which is at least a little less obtrusive.

It may, however, be better to have an additional class (OrderedHash, for
want of a much needed better name), in which order was respected for
both comparison and iteration. 

My main concern is that just making regular hashes respect insertion
order for iteration but not comparison isn't exactly "least surprise";
so far as I know, the iteration order of hashes presently is arbitrary
but not random.  In other words, for any two collections (arrays,
hashes, whatever) it is presently true that:

    a == b

implies

    a.collect { |x| x } == b.collect { |x| x }

but this would no longer be true.

Of course, this line of argument would be weakened if the implication
isn't true at present for hashes.


My preferred answer is to make => an operator that takes two object and
returns a hash in any context (assuming of course that the precedence
issues this raises could by resolved).  That would let people define
their own extension to hash that worked however they wanted.


Or (even better in my book) make anything that matches

      /[:+-=<>|*&^%?~!._]{2,6}/

or some such available as an operator (and thus, the vast majority of
them would be up for grabs for tasks such as this).  Precedence &
associativity could be assigned by some convention (all equal, longer
things lower, or...?) or (though I'm not sure how it could be
implemented) user defined.  

It would require a trick sort of like what is used for tOP_ASGN to keep
the parser from exploding (over 8000000 new operators?  Yikes!) but I
think it might work.

To Hal: would a notation like 

     ordered_hash(1-->2,3-->4,...) 

or 

     1-->2 | 3-->4 | ....

suit you (the latter assuming the precedence could be controlled or the
conventions were fortuitous)?

-- MarkusQ