"Starting to grok the code, I 1st wondered why the type constraints do not need to be written in a string. It seems use MooseX::Types::Moose is responsible for being able to do that."
Moose type constraints are not strings, they are instances of Moose::Meta::TypeConstraint. has (and indeed the Moose::Meta::Attribute class that powers has) just gives you a little sugar allowing you to indicate type constraints as strings. But internally it translates those to type constraint objects.
MooseX::Types basically gives you functions defined along these lines:
# It's actually a lot more complex than this, but just # pretend it's this simple... # sub HashRef () { ### empty prototype return Moose::Meta::TypeConstraint->lookup('HashRef'); }
So that you can use:
isa => HashRef
It also plays some fancy tricks overloading bitwise operators so that HashRef | ArrayRef "just works".
So everything I did in the previous example would work without MooseX::Types; you'd just need to do a bit of work with Moose::Meta::TypeConstraint objects, so it wouldn't look as pretty.
"Indicating, that only the 1st one in the inheritance hierarchy gets propagated. So I assume for it to work independent of how many parent classes were passed, one would have to loop over them in _existing_constraint (how?) and buildup the type constraint before returning it."
Multiple inheritance is always going to make things messier. For example, if you're inheriting from classes A and B where:
package A; has data => (is => 'ro'); package B; has data => (is => 'rw');
... what on earth would you expect to happen?!
In cases like this, I'd want the class that's doing the multi-inheritance to define as much of the data attribute as it can, and rely on its base classes' definitions as little as possible.
In reply to Re^3: Moose "unions" and inheritance
by tobyink
in thread Moose "unions" and inheritance
by PetaMem
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |