How to inject methods

Jonathan Worthington jonathan at jnthn.net
Mon Jun 28 22:00:19 UTC 2010


chromatic wrote:
> Parrot *cannot* support Perl 6 semantics with the current object system.  Full 
> stop.  If we want Rakudo to run efficiently on Parrot and if we want Rakudo to 
> interoperate with other languages on Parrot, we have to fix the object system.
>
>   
+1. While I can go and write an object system that looks how I want for 
Rakudo/NQP-RX, it's not going to have the level of interop that would be 
desirable, so I'd much rather see Parrot level improvements.

> Parrot's conflation of NameSpace and Class requires the clunky initialization 
> system with :load and :init to attempt to create Class instances before 
> runtime.  This is fragile and depends on subtle issues of ordering.
>
>   
Aye. Just to clarify on namespace/class relations, a method *may* end up 
living in a namespace, but only by virtue of it explicitly being 
declared as also going there as well as in the methods table of the 
class. That is, in Perl 6 terms:

    method foo() { } # not in namespace
    our method bar() { } # in namespace

Certainly going in the namespace should not be the default though, which 
is what iirc is what #389 fixed.

Also the class registry probably should die.

> A *declarative* PIR syntax for Classes, attributes, and methods would not 
> require this fragility, because we could set up the Classes at *compilation* 
> time and freeze them into bytecode.
>
>   
A declarative PIR syntax for classes, attributes and methods is not what 
Rakudo needs, though. What I *really* want is Parrot to provide is some 
quite low-level pure prototype-ish object that:

* Can be serialized efficiently - including trees of them

*  Knows how to have native types as attributes

* Can look up said attributes by index as well as string (because most 
Perl 6 attribute lookups should be done by an offset)

* Has a way to let us call methods both dynamically and statically (that 
is, we can resolve method calls whose names are statically known at 
compile time into offset based calls - this probably implies single 
inheritance if we want to be efficient, and that is fine)

Rakudo would then implement it's ClassHOW and RoleHOW (meta-objects for 
Class and Role) in terms of this. Parrot could similarly then provide 
class and role semantics that support something close enough to the 
current Parrot semantics to not make life too much of a nightmare for 
existing developers. (I'd want to implement our ClassHOW/RoleHOW in NQP 
so we can share them amongst backends, essentially making the small 
efficient pure prototype-ish thing our main primitive to port - this is 
somewhat off-topic for Parrot devs, but an important factor for Rakudo's 
object model development).

Note that meta-objects implementing e.g. a class system with multiple 
inheritance would be totally free to do so. It's just that the primitive 
thing at the base of it all should be as simple and optimizable as is 
reasonably possible.

I fully expect Rakudo's class and role definitions to continue to 
compile down to a series of method calls on meta-objects. However, what 
should be possible is that we can then freeze the resulting object 
(/meta-object) tree into the PBC, so that we can just bring it back to 
life later on rather than having to run through re-creating it.

Thanks,

Jonathan



More information about the parrot-dev mailing list