add_role and remove_role on a Class PMC

[Jonathan Worthington]

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