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

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.

Comment on Re^3: Introspection of Moose/Mouse attributes fails to find native trait with `does` Download Code

Replies are listed 'Best First'.
Re^4: Introspection of Moose/Mouse attributes fails to find native trait with `does` by chromatic (Archbishop) on Aug 25, 2011 at 03:50 UTC
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.)	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Introspection of Moose/Mouse attributes fails to find native trait with `does`
by chromatic (Archbishop) on Aug 25, 2011 at 03:50 UTC

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

[reply]
[d/l]