X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=PLANS;h=b4624adfb2ccb821e86cdc449f69cf170a8ebf15;hb=b68c3910da2c412355a44ef1d5c8a46062f94d85;hp=e009272e48e2a8cee088b83b7a363a3d32281d10;hpb=d67145edcc2653d4936d9395e5d63405332b4c1b;p=gitmo%2FMoose.git diff --git a/PLANS b/PLANS index e009272..b4624ad 100644 --- a/PLANS +++ b/PLANS @@ -2,50 +2,111 @@ -- Type Constraints refactor ----------------------------------------------------------- -- move the details of TC construction that are in Moose.pm and - Moose::Util::TypeConstraints into the Moose::Meta::TypeConstraint module +- add support for locally scoped TC -This will make it much easier to generate TCs on their own, without -having to use the sugar layer. This should also clean up their APIs -as well, which will make it easier to subclass them. +This would borrow from MooseX::TypeLibrary to prefix the TC with the name +of the package. It would then be accesible from the outside as the fully +scoped name, but the local attributes would use it first. (this would need support +in the registry for this). + +- look into sugar extensions + +Use roles as sugar layer function providers (ala MooseX::AttributeHelpers). This +would allow custom metaclasses to provide roles to extend the sugar syntax with. + +(NOTE: Talk to phaylon a bit more on this) + +- allow a switch of some kind to optionally turn TC checking off at runtime + +The type checks can get expensive and some people have suggested that allowing +the checks to be turned off would be helpful for deploying into performance +intensive systems. Perhaps this can actually be done as an option to make_immutable? + +- misc. minor bits + +* make the errors for TCs use ->message +* look into localizing the messages too +* make ANON TCs be lazy, so they can possibly be subsituted for the real thing later +* make ANON TCs more introspectable +* add this ... + +# +# Type Definition +# +subtype 'Username', + from 'Str', + where { (/[a-z][a-z0-9]+/i or fail('Invalid character(s)')) + and (length($_) >= 5 or fail('Too short (less than 5 chars)')) + } +on_fail { MyException->throw(value => $_[0], message => $_[1]) }; + +# fail() will just return false unless the call is made via +$tc->check_or_fail($value); + +* and then something like this: + +subtype Foo => as Bar => where { ... } => scoped => -global; +subtype Foo => as Bar => where { ... } => scoped => -local; + +# or -- create an official TC registry API +subtype Foo => as Bar => where { ... } => in __PACKAGE__ ; -Right now the registration of the TC is a by-product of creation in the sugar -layer, this is bad and make extension of TCs difficult. I am not sure if this -registry API should exist as part of Moose::Util::TypeConstraints, or of we -should create a complete registry object itself. +# or (not sure if it would be possible) -This registry should be a singleton, but M::U::TC should enforce that lifecycle +my $Foo = subtype Bar => where { ... }; + +# ---------- + +[17:10] stevan: it should do it if I pass coerce => 1 as part of the attribute definition +[17:12] autarch: what I am not 100% sure of is how to tell it to deep coerce and when to not +[17:13] cause a basic coerce is from A to B +[17:13] hmm +[17:13] which is valid for collection types too +[17:13] deep coercion is what you are asking for +[17:13] yeah +[17:13] so perhaps we add deep_coerce => 1 +[17:13] which will do it +[17:13] that's fine for me +[17:13] k + +coerce_deeply => 1 # reads better + +----------------------------------------------------------- +- TC stuff DONE +----------------------------------------------------------- + +- create an official TC registry API (DONE) + +Right now the registration of the TC is a by-product of creation in the sugar +layer, this is bad and make extension of TCs difficult. I am not sure if this +registry API should exist as part of Moose::Util::TypeConstraints, or of we +should create a complete registry object itself. + +This registry should be a singleton, but M::U::TC should enforce that lifecycle choice so that you can use your own registry if you really want too. I mean parent of the registry. So that I can create my own registry object for a given class, and any retrieval of a type constraint from this object would automatically search parent registries as well. -- refactor the various TC internals to make it more subclassing friendly +- refactor the various TC internals to make it more subclassing friendly (DONE) -This also includes the coercion stuff as well. This should give you what you +This also includes the coercion stuff as well. This should give you what you need to make your object/class bound stuff. -- move the container TCs from MooseX::AttributeHelpers into Moose core - -These have proven so useful for me in the latest $work project that I think -they should really be core. +- move the container TCs from MooseX::AttributeHelpers into Moose core (DONE) -- allow a switch of some kind to optionally turn TC checking off at runtime +These have proven so useful for me in the latest $work project that I think +they should really be core. -The type checks can get expensive and some people have suggested that allowing -the checks to be turned off would be helpful for deploying into performance -intensive systems. Perhaps this can actually be done as an option to make_immutable? - -- misc. minor bits - -* make the errors for TCs use ->message -* look into localizing the messages too -* make ANON TCs be lazy, so they can possibly be subsituted for the real thing later -* make ANON TCs more introspectable +- move the details of TC construction that are in Moose.pm and + Moose::Util::TypeConstraints into the Moose::Meta::TypeConstraint module + (DONE) +This will make it much easier to generate TCs on their own, without +having to use the sugar layer. This should also clean up their APIs +as well, which will make it easier to subclass them. ----------------------------------------------------------- -- Roles refactor