Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^6: Moose role with requirement consuming another role

by Boldra (Deacon)
on Jul 21, 2011 at 11:12 UTC ( [id://915836]=note: print w/replies, xml ) Need Help??


in reply to Re^5: Moose role with requirement consuming another role
in thread Moose role with requirement consuming another role

Ok, then it's clear we are using a different definitions of "abstract base class". You include classes which provide functionality in your definition, I do not. I don't think the Moose documentation you referenced supports your usage.



- Boldra

Replies are listed 'Best First'.
Re^7: Moose role with requirement consuming another role
by Arunbear (Prior) on Jul 21, 2011 at 16:10 UTC
    The documentation I referenced does not define an abstract base class, it only says
    "If you are familiar with the concept of abstract base classes in other languages, you may be tempted to use roles in the same way."
    Since Java is one of those languages that has an abstract base class concept (as well as a mechanism for mandating that certain methods are implemented), I have been referring to the Java style of abstract base classes.

    If the documentation doesn't support this usage, then which usage do you think it supports?

      You're right, I was confusing "abstract base class" with "interface role".

      That documentation mainly talks about interface roles, but in the sentence "Because the role defines the required methods directly, adding a base class to the mix would not achieve anything" presumably refers to the fact that class<-(role or abstract class)<-interface-role won't work if you only meet your interface-role requirements in the child class. "base class" in that sentence should probably be "abstract class or role". The document is really warning that you should instead use class<-interface-role plus class<-(role or abstract class).

      Now if I've understood that correctly, it's still a not explaining the behavior which I'm seeing. If both has and with are evaluated at runtime and not compile-time, putting them in the correct order should mean that a role can fulfill requirements set by another role, with either a subroutine or a Moose attribute, and not only with a subroutine. I don't care that we veered off-topic, because this taught me something, so thanks!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://915836]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (9)
As of 2024-03-28 10:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found