X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=PLANS;h=b4624adfb2ccb821e86cdc449f69cf170a8ebf15;hb=2ae1457eead0263b687bd59cd3630b893618e551;hp=c986a04cbcde50da87cc9cb1e6d9b39f7b76c9c7;hpb=d9b400059075f0cdffc909861da391aff5f7db66;p=gitmo%2FMoose.git diff --git a/PLANS b/PLANS index c986a04..b4624ad 100644 --- a/PLANS +++ b/PLANS @@ -2,33 +2,26 @@ -- Type Constraints refactor ----------------------------------------------------------- -- move the details of TC construction that are in Moose.pm and - Moose::Util::TypeConstraints into the Moose::Meta::TypeConstraint module - -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. - -- 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? - - add support for locally scoped TC -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 +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 +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 @@ -53,11 +46,11 @@ $tc->check_or_fail($value); * and then something like this: subtype Foo => as Bar => where { ... } => scoped => -global; -subtype Foo => as Bar => where { ... } => scoped => -local; +subtype Foo => as Bar => where { ... } => scoped => -local; -# or +# or -subtype Foo => as Bar => where { ... } => in __PACKAGE__ ; +subtype Foo => as Bar => where { ... } => in __PACKAGE__ ; # or (not sure if it would be possible) @@ -66,7 +59,7 @@ 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: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 @@ -77,18 +70,20 @@ my $Foo = subtype Bar => where { ... }; [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. +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 +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 @@ -97,14 +92,22 @@ this object would automatically search parent registries as well. - 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 (DONE) -These have proven so useful for me in the latest $work project that I think +These have proven so useful for me in the latest $work project that I think they should really be core. +- 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 -----------------------------------------------------------