"Black smoke"

[Vasily Chekalkin]

Hello.

I didn't realise how much code depends on Hash keys order. Shame on me. 
Almost all this code was fixed but no all.

Last bit is handling "attributes" in Class.pmc which causes 2 failures 
in Rakudo. Problems are in this snippet of code:


     class AttrInitTest {
         has $.a = 1;
         has $.b = 2;
         has $.c = $.a + $.b;
     };
     say AttrInitTest.new.c;

Because hash keys are in some random order now (which is correct from my 
point of view) attribute $!c some time initialised before other 
attributes. I can see 3 ways of solving this issue.

1. Unmerge keys_revamp branch, but big warning in release notes that 
Hash keys order will be random, merge it after release and implement 
dependency tracking of attributes in Rakudo. "warning", not 
"deprecation" because current behaviour isn't specified.

2. "Fix" Class PMC to use OrderedHash for "attributes" before release. 
This is actually very big change in current timeframe.

3. Polish and apply attached patch which restore ordering of Hash keys. 
  Revert this patch after release. Put big warning message from item 1.

Patch is wrong in many ways because it restores "original" behaviour of 
iterating over hashes. E.g.
a) it doesn't handle INTVAL keys properly.
b) it will hide original problem with attributes. May be not applicable 
  to Rakudo, but for other languages which allows to remove "attribute" 
in runtime we can't guarantee order of them.
c) we continue to support bad habit of relying on Hash keys order.

But for purpose of release it's probably best (fsvo) solution.


-- 
Bacek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hi.patch
Type: text/x-patch
Size: 3425 bytes
Desc: not available
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20090719/01d8f427/attachment.bin>