On Wed, Jul 28, 2010 at 6:02 PM, chromatic <[email protected]> wrote:
> Rakudo and other HLLs could greatly benefit from Parrot sorting out the "How
> and when do I declare a class?" mess. The best way I can see for us to help
> them is to ease the requirement that all classes need declaration in :load
> :init subs when compiling PIR or loading PBC by adding a bytecode segment for
> classes.
I am not sure we need another segment for this. Classes are just
objects. If freeze-thaw isn't cutting it for classes, I think it is
more indicative of general freeze-thaw issues than a situation that
requires special-casing classes.
> This segment should store attribute information (size, name), methods (name,
> pointer to appropriate sub in regular bytecode seg), parent information
> (pointer to other class), and (optional) class name.
On freeze, classes currently store:
* id number (probably a bad idea, given different load orderings are
likely to mess this up)
* name
* associated namespace name and HLL
* ancestry info (parents & roles)
* attribute info
* methods (and vtable overrides, and resolve methods)
> Anonymous classes referred to in bytecode can refer to the appropriate class
> in the segment.
>
> Named classes should also be available by name lookup.
>
> We'll need to add a freeze and thaw mechanism for classes and some mechanism
> by which HLLs can specify which classes they want to freeze, but if we can
> make this work (and it's not too much work), we can improve Rakudo's startup
> immensely.
AFAIK, classes freeze and thaw fine.
.sub 'FooClass' :anon :immediate
$P0 = newclass 'Foo'
.return ($P0)
.end
.sub 'main' :main
# .const 'Sub' $P0 = 'FooClass'
$P0 = get_class 'Foo'
$S0 = $P0
say $S0
.end
> After that, we can figure out some declarative syntax for classes in PIR and
> avoid many other messes.
>
> -- c
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
