in reply to Re^3: 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's DOES defaults to ISA since Perl can't distinguish between base classes and roles/traits.

Perl 5's DOES defaults to isa() because I wrote it that way, because I understand Liskov's substitution principle.

If DOES means "Can I treat this invocant as if it were an object of that type?" (and it does), then clearly an object which is an instance of that type or a subclass of that type should return a true value for that question.

Replies are listed 'Best First'.
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

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

[reply]
[d/l]
[select]
      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.

[reply]
[d/l]

        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.

[reply]

In Section Seekers of Perl Wisdom