http://www.perlmonks.org?node_id=1062654


in reply to Re: perldoc deleted modules
in thread perldoc deleted modules

I'm putting these back in my local installation. Why would I want to read them again? Well, to be honest, they're kind of long and I was reading them a bit at a time at work... well I never finished.

Aside from that, this was work by two exceptional people known for writing that's both fun to read and helpful. By tossing it away you take something that was uncommonly good from Perl. Other languages may have somewhat complete documentation but I don't know one that has documentation quite like Perl's, so people should be careful about what they toss. It's not only the concepts expressed that's important but the form of presentation.

Btw. I'm confused (I think because for me, though I don't like to admit it to myself, C++'s OO == OO) a little on what exactly a role is and how it differs from an abstract class (one or more of which you may inherit from). perlootut equates inheritance with an is a relationship and is sees semantic trouble when you want moreso to express some kind of contract for what your class must be able to do. Even this is muddy to me, conceptually, though I see the difference in code. Is what something *is* not related, depending on your philospophy maybe equivalent, to what it can *do*? I'd rather express it as "is partly a" vs. "is a" than "does" vs. "is". Or is the main thing just that roles can't have member variables -- or can they?

I dunno, I'm used to thinking of the inheritance mechanism in the language as a means to an end, only one of which would be this "is a" relationship. Inheritance is also the means by which you get, in C++, what C#, Java, and COM IDL programmers have a special interface keyword for. Is that what a role is, like a Java interface? Except I've seen in a talk that roles can have implementation -- I guess this is appropriate when some operations can universally be defined in terms of others that must be supplied by the class implementing the role. So in my C++ rut I'm thinking okay, it's like I got to use C++ instead of Java and did an "interface" with a bass class with all pure virtuals but then decided some of them could naturally be implemented down there, and C++ was nice enough to let me do this, all without any extra keywords (with or without cognitive dissonance with what I think I've done). Would I then have a C++ role (mixin = role?) or am I missing something? So getting back to Perl OO, you can't get roles by putting certain kinds of classes in @ISA, ones that complain if certain methods aren't overridden and define a small coherent related set of operations that could usefully be combined with others?

I'm either not getting something about the concept of role or fail to see the advantage of having a keyword to support it vs. existing language mechanisms + external vocabulary.

Have Tom Christianson or Randall Schwartz written anything about roles?