Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^5: Introspection of Moose/Mouse attributes fails to find native trait with `does`

by ikegami (Patriarch)
on Aug 24, 2011 at 23:36 UTC ( [id://922227]=note: print w/replies, xml ) Need Help??


in reply to Re^4: Introspection of Moose/Mouse attributes fails to find native trait with `does`
in thread Introspection of Moose/Mouse attributes fails to find native trait with `does`

Perl says:

DOES checks if the object or class performs the role ROLE. A role is a named group of specific behavior (often methods of particular names and signatures), similar to a class, but not necessarily a complete class by itself. For example, logging or serialization may be roles.

One must assume that types are roles for this definition to be equivalent to yours.

Similarly, you can only use Liskov's substitution principle's to justify DOES using ISA if you assume 1) that the principle applies to roles as well as types, and 2) that types are roles.

I agree that the principle applies to roles, but I'm not convinced that types are necessarily roles. Is there anything to support this assumption?


Back on subject, I went beyond a glance and came up with a researched answer.

Moose attributes don't have a type. isa specifies a type constraint, not a type. The value held by an instance of the attribute has a type, but does is a method of the attribute.

How then can does check the type of the attribute if the attribute doesn't have a type?

does "indicates whether the attribute itself does the given role. The role can be given as a full class name, or as a resolvable trait name. Note that this checks the attribute itself, not its type constraint, so it is checking the attribute's metaclass and any traits applied to the attribute." (Emphasis in original.)

Replies are listed 'Best First'.
Re^6: Introspection of Moose/Mouse attributes fails to find native trait with `does`
by chromatic (Archbishop) on Aug 24, 2011 at 23:59 UTC
    One must assume that types are roles for this definition to be equivalent to yours.

    That's exactly the assumption I made when I came up with roles.

    Is there anything to support this assumption?

    It's one of the two things I insisted on when we were working on Apocalypse 12. (The other is "They're not interfaces in the Java sense. They have to allow code reuse.")

    Now Moose can do what Moose wants, but if Moose roles don't correspond directly to Moose types, one or the other is broken as per the formal model we designed.

    How then can does check the type of the attribute if the attribute doesn't have a type?

    That part I understand. You can squint and say "If it passes the type check, then it must also pass the role check", but I can understand why Moose's MOP wouldn't necessarily want to add a heuristic to guess about that.

      In Moose a Role is (or at least connotes) a Type but a Type is not necessarily a Role. We've had this conversation once at YAPC in Columbus.

      Whether that is broken or not, it's a difference between Moose and Perl6.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2024-03-29 01:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found