I'm invoking the principle that the only stupid question is the one not
asked: 

Larry Wall wrote:
> if indeed properties can be unified with roles (and roles with 
> classes).  

Based on the source material pointed to as your inspiration for roles, I'm
a little confused as to how roles and classes could be unified.  From what
I read in the source material, a key point of a role (well, they weren't
actually calling it a 'role' there, but I'm not recalling the term that
they did use) is that you get to bypass the "diamond inheritence" problem
by relegating member variables to classes, so that when you use multiple
roles to construct a class you don't have to worry about deciding which
version of the variable to access in any given method.  Without that
restraint, exactly how does a role differ from a multiple inheritence
model?  

---

Incidently, I think I've caught on to _one_ of the concepts in the
upcoming object-orientation proposal: linguistically, there's a triad of
"basic verbs" - namely "be", "do", and "have".  If I'm following things
properly, one could think of an object's properties as things that it has,
its methods as things that it does, and its roles as things that it is. 
So

  my Dog $Spot has $spots;

would be a way to create an object inheriting from type Dog which has a
property called $.spots (is there a way to do @.spots?); 

  my Dog $Spot will rollover {...}; 

would be a way to create an object inheriting from type Dog which has a
method called rollover ("will" is used because "does" is essentially a
synonym for "will do", and "do" is a built-in method which often gets
called implicitly to represent the object's primary function); and

  my Dog $Spot is pet; 

would be a way to create an object inheriting from type Dog which has a
role called pet.  

In a similar way, roles can specify things which must be included in order
for the role to be complete.  Just like "is", "will", and "has" could be
thought of as ways of including roles, methods, and variables in an
object, "like", "must", and "needs" could be used respectively to specify
that the object must have the methods and variables in question added to
it to be considered complete.  "like" probably needs some clarification,
in that saying that an object is "like" a role means that the object takes
all of that role's methods and variables as requirements (that is, it
requires methods with the same name and signature and properties with the
same name and type), in addition to whatever requirements said role
normally contributes.  

Am I following?  

=====
Jonathan "Dataweaver" Lang

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

Reply via email to