----- Original Message ----
> From: Hans Dieter Pearcey <[email protected]>
> To: moose <[email protected]>
> Sent: Tuesday, September 8, 2009 10:32:50 AM
> Subject: MooseX::Types to core?
>
> Whenever we've talked about coring MooseX modules, it's mostly been MXAH and
> MooseX::Types. Does anyone have any changes they'd like to see in MX::Types
> before it becomes, say, Moose::Types? (Moose::TypeConstraints?)
>
> For myself:
>
> * Warn/die on subtype DeclaredType => as Foo => where { ... } (accidental
> stringification) -- I thought someone had fixed this, but it came up as a
> silent failure recently, so maybe not in all cases?
>
> * Standardize on a best practice for parameterized non-global types (e.g.
> ArrayRef[MyObject] vs. ArrayRefOfMyObject) and make documentation use it
> consistently
> * if the former, the RT bug about coercions needs to be fixed
>
> * smarter renaming of imports -- e.g. if you try to import Foo from a type
> library, with -prefix => 'My', it'd really be nice to get to_MyFoo and
> is_MyFoo helpers instead of Myto_Foo and Myis_Foo
>
> * MooseX::Types::Moose -> Moose::Types::Native (maybe)
>
> * Should Structured be included?
>
> hdp.
I've spent a lot of time thinking about the intersections of Moose and Type
Constraints. My general conclusion is that I think it's correct that TC and
Moose general be detached (and I'd love to see more detachment) since people
have uses for type constraints beyond Moose. That said, I think there is a
bigger connection between TC and Class::MOP, since my imagination is telling me
that Moose will eventually be more and more about suger and use, and
functionality will migrate toward CMOP. For example, I know we keep kicking
around the idea that Roles should be in CMOP. I also personally think some of
the bits in MooseX::Declare related to method signatures should either be in
CMOP or at least coordinated with a more rigorous interface defined by CMOP. So
again, my imagination is saying type constraints are build on top of CMOP, and
consumed by Moose or others.
My longish term plans for this would include a default set of types that would
be a superset of the current (probably would include datetime stuff and maybe
set stuff that is useful to the database people) as well as a superset of
functionality. I'd probably build something out from the ideas in the
MooseX::Dependent stuff in the repo, so that all types could be parameterzied
or faceted (making it easy to say subtype ShortString, as Str[MaxLength=>5]; )
and adding some facility for traits or roles to types. This would be so you
could define a trait like 'hasMinSize' and it could be meaningfully conposed
into any TC that defines a 'size' method. something sorta like:
subtype AtLeast3Characters,
as Str[MinSize=>3],
with hasMinSize,
where 'size' {
my ($tc, $value) = @_;
return $tc->{MinSize} > length $value;
};
Just a wild guess right now.
John