Hi all,

I have filled another role-related issue today. While the issue is just another 
bug in the compiler, it stems from the thing which I consider to be a big 
problem about what a Role is in Perl6. Or, more precisely, from the fact that 
Role is an entity deprived of its civil rights.

What functionality would I expect from a Role? Two things:

1. Define interfaces
2. Define abstract behaviors

What Perl6 is currently providing me with? Interfaces – ok; behaviors – only 
partially. For example, there is no guarantee that a BUILD or TWEAK submethod 
defined in a Role would ever be run, unless a class does special measures to 
ensure them be executed.

What I expect a Role to be? Perhaps, more of a degraded Class in a way that 
roles would be able to participate in MRO resolution, for example. In a way 
that roles must be able to participate in object initialization process equally 
to classes; after all, isn't this a part of object behavior too?

If somebody would like to object by saying that "Role isn't a Class" then think 
about punning first.

Not to mention the ability of declaring per-role 'our' objects which is not 
critical but would be handy sometimes.

Having the roles to be so special seemingly causes lots of unwanted side 
effects and bugs. For example, https://github.com/rakudo/rakudo/issues/2657, 
https://github.com/rakudo/rakudo/issues/2496, and 
https://github.com/rakudo/rakudo/issues/2282 just wouldn't exists with roles 
being part of MRO. An attribute object would probably have its .package 
attribute set correctly. And couple of other issues.

Basically, at this moment I consider carefully if I need a role or there is 
another way to implement something. Because what is known for sure now: there 
will be problems, sooner or later!

Maybe somebody could explain clearly why things are the way they are now. I 
would be very thankful for such information. Perhaps I need a tectonic shift in 
my understanding of this area. But currently roles are the only thing which 
really disappoints me in the language design.

Best regards,
Vadim Belman

Reply via email to