On Fri, Feb 13, 2009 at 4:53 AM, William James <w_a_x_man / yahoo.com> wrote:

> James Coglan wrote:
>
> > >
> > > Your code happened to work by chance.
> >
> >
> > Granted. As I've said elsewhere, this is just my example of a
> > significant change in 1.8.7. I accept that no iteration order was
> > ever explicitly stated for 1.8, and a change like this is something
> > of a grey area in terms of whether it would be considered a backward
> > incompatibility.
>
> No, it's not a gray area.  Anyone who has a basic understanding of
> hash-tables doesn't even think about the iteration order.


Let me try to calm the waters on this particular part of the conversation.

A couple of years ago, there was a long discussion here, when some, led by
Hal Fulton IIRC,  advocated defining the order for enumerating Ruby hashes.

At that time, I argued vehemently to your point that hash tables are
inherently unordered, and therefore it was inconceivable to order them.

I was wrong.

First, although Ruby Hash is implemented using a hash table, they aren't
hash tables, they are Ruby objects which for better or worse are named
simply Hash.  Perhaps if they had been named something like Dictionary, or
Map, a name which doesn't betray the implementation, this all would have
been less controversial.

Sometime after that discussion, Matz, who I know has much more than a basic
understanding of hash-tables, decided that, yes,
defining the iteration order of Ruby hashes to  be by insertion order, and
that this was easily done with minimal impact to performance/space
requirements by linking buckets in the internal hash table used to IMPLEMENT
Hash, and made this change in Ruby 1.9, which has been backported to Ruby
1.8.7.

And as for whether or not changing something which was previously undefined
to something which is defined introduces a backwards compatibility issue, I
think it's pretty clear that it does not.

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale