Jonathan Lang writes:
> I've just been rereading the recent discussions, and I noticed something
> that I missed the first time: 
> 
> Larry Wall wrote:
> > Traits are not definitional but rather operationally defined in the 
> > worst way.  That's why traits are renegade roles.  They don't play by 
> > the rules.
> 
> In other words, a trait effectively has an "installer" routine which
> gets run whenever you apply it to a particular object (that is, "is
> const" calls const::INSTALL or something of the sort).  
> 
> I've been trying to puzzle out what the distinction between roles and
> traits is so that I can understand why traits need to be handled
> differently than roles are - in particular, I was thinking in terms of
> why traits don't fit into the "order of precedence" for method calls
> (that is, class || role || superclass).  If I'm right about the
> installer, the answer would seem to be that the trait gets to choose
> (by means of the installer) where it fits into said chain, if at all -
> it could insert itself into the class's ISA list, tell the class to
> treat it as a role, or maybe even wrest control from the class,
> effectively treating the class definition as a role or superclass of
> its own and then masquerading as the class to outsiders (effectively
> putting itself ahead of the class in the order of precedence chain).
> Or it could do none of the above, thus requiring its namespace to be
> explicitly referenced if you want access to any of its methods or
> attributes.  
> 
> The point is that - if I'm understanding the current thoughts on the
> subject - the difference between a trait and a role is that a trait's
> interaction with a class is programmable.  How am I faring?  

That seems to be it.  A trait, from the user's perspective, is something
declarative that happens other than inheritance or role composition.  If
you're wondering why roles aren't unified with traits, it looks like a
linguistic thing.  We only have so many naming conventions.

Traits are the catch-all of encapsulated behavior.  You put something
that happens behind a name, and it does what it needs to in order to
fulfill its duty.  For the things more specific, there are concepts more
specific.

I think traits are a brilliant idea though.  If you're going to hack,
it's nice to have a standard way to encapsulate the hack.

Luke

Reply via email to