"Black smoke"

Patrick R. Michaud pmichaud at pobox.com
Sun Jul 19 07:10:21 UTC 2009


I've now committed a "fix" into Rakudo (e759b14).  What Rakudo
now does is to maintain a parallel ResizableStringArray of attribute
names in the order in which they were declared (added) to the class,
and when that list is present Rakudo uses the list to determine the order
of attribute initialization.  (If the list is not present, as is the
case for classes not created from Perl 6 code, then Rakudo falls back
to introspecting the class for a list of attribute names and the
order of attribute initialization is considered unimportant.)

This should work for the time being.  Longer term, I think that
we may want the Class PMC to use something like an OrderedHash
so that HLL implementations can maintain _some_ control over
the sequencing of attribute slots in a class.

Pm

On Sat, Jul 18, 2009 at 10:21:07PM -0400, Andrew Whitworth wrote:
> Talked to Patrick tonight in IRC and he suggested that we not back out
> the branch changes until tomorrow night. He thinks Rakudo may be able
> to implement a fix on their end before the release. If it doesn't get
> resolved by then, or a solid plan isn't started to get it resolved
> shortly thereafter, we can talk about backing out the merge. Sound
> good?
> 
> --Andrew Whitworth
> 
> On Sat, Jul 18, 2009 at 8:09 PM, Vasily Chekalkin<bacek at bacek.com> wrote:
> > 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
> >
> > _______________________________________________
> > http://lists.parrot.org/mailman/listinfo/parrot-dev
> >
> >
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev


More information about the parrot-dev mailing list