Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Classes Suck. ROLES are the new best thing

Name: Anonymous 2010-09-09 15:09

quote:

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
 }

Name: HAXUS THE SUMMARY 2010-09-09 15:29

New Perl includes yet more features; surprises nobody.

Name: Anonymous 2010-09-09 15:31

>>2
You are missing the point. Is not a post about perl or perl6. It is a post about ROLES.

Name: Anonymous 2010-09-09 15:33


...
}
role Duck {
...
}
role Rick {
...

Name: Anonymous 2010-09-09 15:37

So it's an abstract class.

Name: Anonymous 2010-09-09 15:44

>>5

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.

Name: Anonymous 2010-09-09 15:52

monadic anus

Name: Anonymous 2010-09-09 16:06

>>4

No.

Name: Anonymous 2010-09-09 16:12

>>6
Can you not add and remove classes at run time in Perl?

Name: Anonymous 2010-09-09 16:46

Let me fix this >>6

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: Anonymous 2010-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!!!

Name: Anonymous 2010-09-09 16:52

ITT some idiot just rediscovered interfaces.

Name: Anonymous 2010-09-09 17:01

Name: Anonymous 2010-09-09 18:05

>>10
There's no reason you couldn't do the same with classes.

Name: Anonymous 2010-09-09 18:08

So Perl ripped off Go? How quaint.

Name: Anonymous 2010-09-09 19:29

>>15
Yes. Ten years in advance. Perl 6 has time travel. Go didn't invent dick-typinginterfaces.

Don't feel too bad, >>1 is an even bigger faggot.

Name: Anonymous 2010-09-09 21:22

>>16
Learn to recognise sarcasm, imageboard person.

Name: Anonymous 2010-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.

Name: Anonymous 2010-09-09 21:36

Trying to get closer to multiple inheritance without quite fully providing it?

Name: Anonymous 2010-09-09 21:37

>>18
You shouldn't be programming at all.

Name: Anonymous 2010-09-09 21:43

>>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.

Name: Anonymous 2010-09-09 21:45

>>21
>>20-san was right.

Name: Anonymous 2010-09-09 22:09

>>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.

Name: Anonymous 2010-09-10 0:38

>>23
This conversation is going around in circles.

Name: Anonymous 2010-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: Anonymous 2010-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.

Name: Anonymous 2010-09-10 6:19

`Roles'? Why rename a concept that has existed since forever.

Name: Anonymous 2010-09-10 9:32

>>27
Why use Perl?

Name: Anonymous 2010-09-10 10:35

>>27
And that concept is????

Name: Anonymous 2010-09-10 13:20

>>29
Inheritance, except their implementation is broken.

Name: HASKELUS THE TYPECLASSER 2010-09-10 13:27

Too slow!

Name: Anonymous 2010-09-10 13:32

>>30
perl
broken

Well I never!

Name: Anonymous 2010-09-10 14:08

OP here, to all 'roles' haterz..

http://www.slideshare.net/Ovid/inheritance-versus-roles-1799996

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.

http://www.youtube.com/watch?v=7O09FPHuCQQ (skip to 3:30)

Name: Anonymous 2010-09-10 14:33

>>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.

Name: Anonymous 2010-09-10 14:34

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.

Name: Anonymous 2010-09-10 15:08

>>33
[flash needed]
crap

Name: Anonymous 2010-09-10 16:03

>>35
Are roles not inherited? That sounds problematic.

Name: Anonymous 2010-09-10 16:25

entity systems

Name: Anonymous 2010-09-10 16:50

For what i see, (1st link in >>33) roles are a way to "keeping clean" the classes. OP is an idiot for implying that classes are opposed to roles

Name: Anonymous 2010-09-10 18:09

>>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.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List