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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
