Hmmm,
Okay, well to fix the first case I think we need to simply add a
is_any_parent_parameterized or something to the core TC objects and we
can check that when creating the accessor. This will catch the type
alias cases and maybe a few others (anon-subtypes).
For the second case, perhaps we need a new type of TC object that is a
parameterized type with a where clause. Instead of the accessor just
checking the parameter type it will also do a check on the entire
value itself after the operation has been completed.
Thoughts?
- Stevan
On Aug 26, 2009, at 1:06 PM, Jesse Luehrs wrote:
On Fri, Aug 21, 2009 at 09:22:26AM -0700, Hans Dieter Pearcey wrote:
As far as I know, nothing else needs to be done for this branch.
Jesse, Chris,
or Shawn -- anything I missed?
Something brought up by mo on #moose a day or two ago:
package Foo;
use Moose;
use Moose::Util::TypeConstraints;
subtype 'Bar', as 'ArrayRef[Int]';
has bar => (
traits => [qw(Array)],
is => 'ro',
isa => 'Bar',
default => sub { [] },
handles => {
push_bar => 'push',
},
);
my $foo = Foo->new;
$foo->push_bar('baz') # this doesn't throw an error
Basically, the only case that we actually check for when deciding
whether the accessor should do a type constraint check is when the
constraint is literally 'ArrayRef[Foo]'. I don't think that any
auto-generated accessors should allow the type constraint to be
violated.
The most straightforward solution I can see is to figure out if the
type
constraint is a bare wrapper around the appropriate parameterized
constraint (like above), if it is, then search through the hierarchy
to
find the proper constraint to check. If it's not, then we really
have no
choice but to do a full check of the constraint on every
modification -
consider constraints like
"subtype 'Foo', as 'ArrayRef[Int]', where { sum(@$_) < 5 };
- there's really no way to express that as a partial type constraint
check without doing really ugly things.
Thoughts? Better solutions?
-doy
