--000e0cd2454eb8f0840462ca0e38
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

2009/2/13 William James <w_a_x_man / yahoo.com>

> 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.


Not true. Some languages (Ruby 1.9, most JavaScript implementations) iterate
over hashtables in insertion order. This is often done (as it is in Ruby) by
storing the table entries as a linked list so that every entry has pointers
to its neighbours. Though a basic hashtable implementation will not
guarantee iteration order, there is potential confusion if an implementation
*appears* to guarantee it. I referred to this is a grey area because 1.8
never made any such promises, it just *looked* like it did in some use cases
until 1.8.7.

Anyway, this has gone a little off-topic. As previously stated, I would
point out that http://github.com/jcoglan/packr/tree/3.1 still has a
regex-related bug under 1.8.7 that I've not found a fix for and that does
not appear in any other 1.8 or 1.9 release. If anyone has had regex issues
on 1.8.7 I'd really love some help fixing my bug!

--000e0cd2454eb8f0840462ca0e38--