----- Original Message ----
> From: Stevan Little <stevan.lit...@iinteractive.com>
> To: Jesse Luehrs <d...@tozt.net>
> Cc: Hans Dieter Pearcey <h...@pobox.com>; moose <moose@perl.org>
> Sent: Wednesday, August 26, 2009 2:26:35 PM
> Subject: Re: More on Native Traits
>
> 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
I ran into similar trouble when playing with the MooseX::Dependent stuff in the
git repo, mostly when adding dependencies to existing parameterized types, I
had to jump through a lot of hoops.
>From my perspective I foresee all types someday being 'parameterized' (or
>facted, whatever) so that we can support basic facet build in to types, like
>ArrayRef(of(Int), hasMaxLength(10)) and Str(hasPattern(qr(/d/d-/d/d/d/d/)) or
>something like that. So somewhat to test this up the stack would be useful I
>think.
john
>
> 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
