Roles in Perl 6 take on the function of interfaces in Java, mixins in Ruby, and traits[26] in the Smalltalk variant Squeak. These are much like classes, but are entirely abstract. These are used to perform composition when used with classes rather than adding to their inheritance chain. Roles define nominal types; they provide semantic names for collections of behavior and state. The fundamental difference between a role and a class is that classes are instantiable; roles are not.[27]
Essentially, a role is a bundle of (possibly abstract) methods and attributes that can be added to a class without using inheritance. A role can even be added to an individual object; in this case, Perl 6 will create an anonymous subclass, add the role to the subclass, and change the object's class to the anonymous subclass.
For example, a Dog is a Mammal. Dogs inherit certain characteristics from Mammals, such as mammary glands and (through Mammal's parent, Vertebrate) a backbone. Dogs may have one of several distinct types of behavior; for example, a Dog may be a Pet, a Stray, or a Guide for the blind. However, these are simply sets of additional behaviors that can be added to a Dog; a Cat can equally be a Pet or Stray, for example. Hence, Dog and Mammal are classes, while Pet, Stray, and Guide are roles.
class Mammal is Vertebrate {
. . .
}
class Dog is Mammal {
. . .
}
role Pet {
. . .
}
role Stray {
. . .
}
role Guide {
. . .
}
Roles are added to a class or object with the does keyword, as opposed to inheritance's is. The keywords reflect the differing meanings of the two features: role composition gives a class the behavior of the role, but doesn't indicate that it is truly the same thing as the role.
class GuideDog is Dog does Guide {
. . .
} # Subclass composes role
my $dog = new Dog;
$dog does Guide; # Individual object composes role
Although roles are distinct from classes, both are types, so a role can appear in a variable declaration where one would normally put a class. For example, a Blind role for a Human could include an attribute of type Guide; this attribute could contain a Guide Dog, a Guide Horse, a Guide Human, or even a Guide Machine.
class Human {
has Dog $dog; # Can contain any kind of Dog, whether it does the
... # Guide role or not
}
role Blind {
has Guide $guide; # Can contain any object that does the Guide role,
... # whether it is a Dog or something else
}
Yes but you can add or remove roles at run time also. A silly example: in a game a wizard enchants a horse and become a pegasus. You just "add" the "CanFly" and "HasWings" roles to the now horse.
Yes but you can add or remove roles TO AN OBJECT at run time also. A silly example: in a game a wizard enchants a "Horse" OBJECT and become a pegasus. You just "add" the "CanFly" and "HasWings" roles to the now horse.
Roles, then, are a collection of states and behavoirs, than can be attached or removed from objects in runtime.
Name:
Anonymous2010-09-09 16:46
This is what got me interested in Perl 6. I am still looking into Perl 6 for daily applications but Perl 5 is very much still out there.
Perhaps if Perl 6 hadn't been vaporware for so god damn long!!!
>>16
Learn to recognise sarcasm, imageboard person.
Name:
Anonymous2010-09-09 21:26
he, thanks op. really, i was just looking for a way to model financial instruments in an elegant way... roles seems to be my solution. I think i'll go with ruby mixins though.. i can't wait two more years to have a production-ready perl6.
>>20
Do you have ANY idea of the huge ammounts of types of financial instruments that exists nowadays???. I don't think so .And financial instruments are not universal. For example, muslim banking has a totally different kind of "financial thinking" and their instruments reflects. Roles are clearly the best solution IMO since you can have a small hierarchy tree and a bag of behavoirs.
>>19
If you want to talk about inheritance, perhaps you should look up Perl 6's inheritance model. Having a role just means you'll type-check. It's a work permit. It doesn't give you anything else you didn't already have, not the skills nor equipment to do the job you signed up for.
>>23
This conversation is going around in circles.
Name:
Anonymous2010-09-10 2:56
>>21
You are totally right. Inheritance does bring a lot of head aches in a financial point of view. I remember when uncle died there were a lot of questions of who'd get what. Luckily for me my father had the role of the only living sibling, and he got it all.
Name:
Anonymous2010-09-10 5:18
Flying is a role seen in nature. Although it is often an inheritied trait from parents in birds etc.. It is also a role that has developed independantly in evolutionary branches that are only very distantly related - egs bird and bats.
Very interesting discussion about roles over inheritance
--------
I have an ideological bias against organizing everything by Hierarchies. If anyone wonders why, take a look at this video. Not /prog/ related but you wont miss those 20 minutes of your life.
>>26
Like that's got shit to do with inheritance in programs? You're supposed to model your problem, not some completely unrelated details of the real world.
Why do people think roles have anything to do with inheritance? Even in >>33 there's a link to a comparison by someone who should know better. They've got nothing to do with one another and they don't even interact, making it painless for a language to provide both.
>>37
Nothing about roles requires it. I don't remember whether Perl's do. Suppose they're not; how hard do you think it is to fix an instance of your derived class?
The question is meaningless to Go's interfaces. Anything that can qualify as an interface does--now that is cause for concern. It's only rarely going to be a problem, but if it ever comes up it's the worst kind of problem to have: complete and utter ambiguity.
>>41
Semantics. And in Go's case, if it compiles... well that don't mean a thing. This, in the face of the draconian emphasis on type safety. It's not that bad unless someone slips up pretty bad... but then that's just what type safety is supposed to prevent.
Multiple inheritance, polymorphism, classes, and now roles, they're all just a bunch of enterprise-speak for keeping related blobs of data together and treating them as one entity with different possible operations.
The term `role' suggests a method may have different behavior with respect to different roles it can fulfill. `Interface' is a better term for indicating a set of features and behaviors.
So Perl now has aliased mixins to ``roles'', just like Ruby aliased them to ``modules''.
[b][i][o]Fascinating.[/b][/i][/o]
Name:
Anonymous2011-04-06 23:29
>>82
Who needs mixins, if instead of `objects` we can use lists? This mathematical OOP bullshit is just plainly retarded. Fuckin jews and their Set Theory...
Name:
Anonymous2011-04-06 23:32
'(dog (roles mammal pet stray guide))
It's that simple.
Name:
Anonymous2011-04-06 23:39
Perl sucks.
Sincerely yours,
Anonymous
Name:
Anonymous2011-04-06 23:55
perl sucks. long live perl.
Name:
Anonymous2011-04-07 6:41
I thought, roles/interfaces were a fix for missing multiple inheritance.
If you have multiple inheritance as in perl 6, what exactly can you do with roles that you can't already do with classes?
>>100
They have composition and dispatch for two. They apply to types (and instances) and also cause changes relevant to the type system. They're completely abstract.
do you mean methods and attributes, fuckface? what you're proposing is making my code harder to understand that this spaghetti deaghuujmj shit already is