Nature of traits

2003-12-21 Thread Jonathan Lang
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?  

=
Jonathan Dataweaver Lang

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/


Re: Nature of traits

2003-12-21 Thread Luke Palmer
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