Larry,

This means that Roles are now first-class-ish things. Meaning they cannot just simply be composed into classes since now we have to keep a table of elements which are private to a Role.

I personally don't like this, I think it brings us back to Mix-ins and (possibly) looses some of the benefits of Roles. But that is just my initial gut reaction. I am going to have to let is sink in a little more to know for sure. In the meantime I have some questions:

On Jul 21, 2005, at 2:48 PM, Larry Wall wrote:
    * All roles can write their shared attributes as $.x and not worry
        about whether the class declares them or not.

I assume they need not worry because we can rely on conflict resolution to deal with most issues? Or are you thinking something different?

    * All roles can write completely private $x attributes that are not
        visible outside their lexical scope but are nevertheless per-instance.

So the Role's scope is preserved here, as opposed to pushing $x into the classes scope. Correct?

* All roles can write explicitly shared $_x attributes that are private
        to the class but visible to other roles and trusted classes.

What other roles? the other roles that the class does()? This would make it difficult to compose role methods into the method table without bringing along a lot of meta-info about from whence they came. It is doable I think, but adds some complexity for which I am not sure the cost outweighs the benefits.


Have at it...

Stevan

Reply via email to