First the question is are Roles and Types are Symmetric. In Moose they are not, effectively Roles are a subset of Types in Moose. This means that just because an attribute has a Type, and a value that satisfies that Type is stored, that does not automatically mean that an attribute’s value does a Role equivalent to that Type. There may not be a Role that is equivalent to that type.

Second, and it took me a second to notice this, but he’s checking the Attribute MetaObject’s does(). The Type is a property of the value stored in the attribute, not necessarily a property of the attribute itself. So even if the first were resolved such that a Type automatically implied a Role on the value, this check wouldn’t be the proper one for it.

Third, if the poster is in fact looking to test a property of the MetaObject, and if we all agree that the best way to test/implement this is via a Role on the MetaObject, I’m not sure calling that trait after the Type name is the most intelligent design choice. It would lead to a collision with the way Moose’s implicit type auto-vivification happens.

Second, and it took me a second to notice this, but he’s checking the Attribute MetaObject’s does().

Yeah, and that's a user interface question. I could argue that interpretation both ways, depending on how I felt about metacircularity.

There may not be a Role that is equivalent to that type.

I've said this before, but I'll write it again to clarify for everyone else:

Any declaration of a type which does not imply the existence of a role is broken, in my opinion. A system is allomorphic only if every named class or type implies a role.

With that said, a system doesn't have to be allomorphic to be useful, but a fully allomorphic system has the fewest possible edge cases and the greatest possible flexibility, and that's pretty much exactly what we're after with roles.

(I don't have a formalism to specify the relationship of anonymous classes and anonymous roles because I haven't figured out a good way to specify the identity of an anonymous type. There's an easy and obvious solution but I haven't proven to my satisfaction that it's watertight.)

At a glance, I'd say:

Perl's DOES defaults to ISA since Perl can't distinguish between base classes and roles/traits.

Moose can distinguish between base classes and roles/traits, so it doesn't need to fallback to Perl's inaccurate default.

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.

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

Basically (and perigrin already said this sorta), the OP is introspecting a meta-object, not any kind of prototypical value that would be stored by the attribute. So really, there should be no reason that $attr->does('Bool') using the traditional meaning of does.

Next, the whole traits => ['Bool'] thing needs to be understood. By adding the 'Bool' trait to the attribute you are really just asking Moose to (optionally) provide delegate-able methods (specific in this case to Bool values). So in this particular case you could do the following:

has 'guernsey' => ( 
    traitls => [ 'Bool' ],
    is => 'rw',
    isa => 'Bool',
    handles => {
        be_a_guersey => 'set',
        dont_be_a_guernsey => 'unset',
    }
);
[download]

my $cow = MyCow->new;
$cow->be_a_guernsey();
[download]

So, while I can see that these things can be a little misleading initially. Once you learn what all the pieces are made of, and roughly how they fit together, it should make sense going forward because it is really pretty consistent.