On 21/02/2011 14:36, Andrew Whitworth wrote:
By my understanding, the current implementation of roles has either
never worked or never really been tested. This would be a major reason
why such sanity checks on the system fail.
It worked well enough for Rakudo to get a first cut at roles off the
ground, and is still somewhat used in Rakudo today (though 6model will
bring an end to that). So it's certainly been in use and useful for a
while now, albeit with serious flaws (which, of course, were much harder
to see when they were initially implemented).
The big question in my mind is whether we want to try to fix and test
this system as-is, or wait for our new MOP implementation (which, I
assume, will support roles out of the box).
While I won't try to answer that question, I'd like to comment on the
assumption. :-) My feeling on the "what to support out of the box" these
days is that the MOP needs to provide just enough in its core to allow
all of the interesting stuff to be implemented in terms of it, and
assume as little as it reasonably can. To take 6model as an example, the
core doesn't even know what inheritance or flattening composition is,
much less what a role or a class is.
Languages differ a bunch on how they think classes work. Some don't even
have classes, but prototypes objects. Roles are new enough an idea that
I suspect it's unrealistic to expect languages that have them to have
anything close to a common agreement on how they work. For example, Perl
6 wants any mention of $?CLASS in the role to be generic, so
implementing Perl 6 style roles means implementing at least some basic
form of parametric polymorphism - even if you don't really implement
"parametric roles" per se. However, I can easily conceive of a language
wanting to do roles, but satisfied by a much simpler implementation. Or
maybe it has a different conflict resolution mechanism, or...well, the
list goes on. :-)
Parrot could provide a set of meta-objects that give the same kind of
basic class semantics that are provided by Class today, and some set of
role semantics too if desired, but just as a set of defaults. Language
developers could pick them up in order to get started, but they could
just as reasonably go and write their own set of meta-objects that
provide the semantics their language needs. In fact, the expectation
should probably be that they will need to do so at some point into their
HLL development, unless the HLL has very limited OO needs.
Thanks,
Jonathan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
