X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=gitmo%2FMoose.git;a=blobdiff_plain;f=TODO;h=3026a87949c4c165c8ce2a51775858c4b71a988f;hp=cd90526dc99ca1376422331adc482634141b1df1;hb=280fffdceb77bdc95701c60dc322a97cc89de81d;hpb=ef0801e7baae50deb984db083b25bf1cde032c96 diff --git a/TODO b/TODO index cd90526..3026a87 100644 --- a/TODO +++ b/TODO @@ -1,9 +1,10 @@ -== Todo for 2.0400 +# vim: set ft=markdown : -=== RT Tickets +## Uncontroversial Items -RT#67731 - Union types reports spurious parent types - -https://rt.cpan.org/Ticket/Display.html?id=67731 +These items are reasonably well thought out, and can go in any major release. + +### RT Tickets RT#59478/RT#63000 - 0+ overload causes NV conversion on == on perls before 5.14 - this causes comparisons to fail when the number can't fit in an NV @@ -11,29 +12,16 @@ without precision loss. I'd like to fix this in a more general way (forcing anyone else who might be using == on tc objects to do weird things isn't very good), although it's hard to test to see what actually works. -RT#69839 - UNIVERSAL methods should show up as methods, so things like method -modifiers work - -=== Register implicitly created class/role types - -When you do has foo => (isa => 'Bar'), it returns a class_type for Bar, but -doesn't register it. This means that later you can declare "subtype 'Bar', as -'Str', ..." and it'll work, and later instances of the 'Bar' type will use that -one. We should register the implicitly created ones so that trying to redefine -it after it's used throws an error. - -== Todo for 2.0600 - -=== Revise MetaRole API to reunify class/role metaroles: +### Revise MetaRole API to reunify class/role metaroles: - apply_metaroles( - for => $meta, - roles => { - attribute => [...], - class => [...], - role_attribute => [ ... ], - } - ); + apply_metaroles( + for => $meta, + roles => { + attribute => [...], + class => [...], + role_attribute => [ ... ], + } + ); If the $meta is a class, we apply the roles to the class. If it's a role, we hold onto them and apply them as part of applying the role to a class. @@ -44,33 +32,36 @@ also need to store method modifiers with their original role, which may mean adding some sort of Moose::Meta::Role::MethodModifier class. For each role-specific thing (methods, attributes, etc.) we should allow a -role_attribute, role_method, etc. key. The common case will be that the +`role_attribute`, `role_method`, etc. key. The common case will be that the metaroles are intended for the consuming class, but we should allow for metaroles on the role's metaobjects as well. -=== Deprecate old-style Moose extensions +### Deprecate old-style Moose extensions -Moose extensions that work by calling Moose->init_meta(metaclass => -'Some::Custom::Metaclass', ...) during their own init_meta should be +Moose extensions that work by calling `Moose->init_meta(metaclass => +'Some::Custom::Metaclass', ...)` during their own `init_meta` should be deprecated, so they can be removed later (this should fix the issues with -init_meta generation in Moose::Exporter, see RT51561) +`init_meta` generation in Moose::Exporter, see RT51561) + +This needs to wait until the previous fix gets in, since it will hopefully +eliminate the need to write custom `init_meta` methods entirely. -=== Attributes in roles need to be able to participate in role composition +### Attributes in roles need to be able to participate in role composition Right now, this fails with no decent workaround: - package R1; - use Moose::Role; - has foo => (is => 'ro'); + package R1; + use Moose::Role; + has foo => (is => 'ro'); - package R2; - use Moose::Role; - with 'R1'; - requires 'foo'; + package R2; + use Moose::Role; + with 'R1'; + requires 'foo'; - package C; - use Moose; - with 'R2'; + package C; + use Moose; + with 'R2'; Role attributes really need to be able to participate in role-role combination. This should also fix "with 'Role1', 'Role2'" being broken when Role1 implements @@ -78,40 +69,50 @@ a method as an accessor and Role2 requires that method, but at least in that case you can split it into two 'with' statements with minimal loss of functionality. -=== Method modifiers in roles should silently add 'requires' for them +### Method modifiers in roles should silently add 'requires' for them This shouldn't be a functionality change, just a better error message (and better introspectability). This shouldn't happen if the role already contains a method by that name, so it'll depend on the previous fix going in (so "has foo => (is => 'ro'); around foo => sub { }" doesn't produce a 'requires' entry). -=== Add overloading support +### has +foo in roles + +There's no actual reason for this not to work, and it gets asked often enough +that we really should just do it at some point. + +### use Sub::Identify instead of doing our own thing with `get_code_info` + +No idea why we stopped using Sub::Identify in the past, but there's no reason +not to do this. We have a bug fix in our version (the `isGV_with_GP` thing), so +this should be submitted to Sub::Identify first. + +## Needs Thought + +These are things we think are good ideas, but they need more fleshing out. + +### Add overloading support or at least, don't break existing overloading support This shouldn't treat the overloading stuff as actual methods, since that's just -an implementation detail, but we should provide an API for add_overload, -get_overload, get_overload_list, etc. In particular, this would allow +an implementation detail, but we should provide an API for `add_overload`, +`get_overload`, `get_overload_list`, etc. In particular, this would allow namespace::autoclean to not break things. Also, MooseX::Role::WithOverloading should probably be cored. +This should probably also wait for the metarole unification fix, to avoid the +::WithOverloading stuff being too insane. -== Todo for later - -=== has +foo in roles - -There's no actual reason for this not to work, and it gets asked often enough -that we really should just do it at some point. - -=== Actual API for metaclass extensions +### Actual API for metaclass extensions Right now, the only way to bundle multiple metaclass traits is via Moose::Exporter. This is unhelpful if you want to apply the extension to a metaclass object rather than a class you're actually writing. We should come up with an API for doing this. -=== MooseX::NonMoose in core +### MooseX::NonMoose in core I think all of the actual issues are solved at this point. The only issue is the (necessary) implementation weirdness - it sets up multiple inheritance @@ -120,7 +121,7 @@ constructor method at 'extends' time (although perhaps this could be solved by moving some of the logic back into Moose::Object::new?). Other than that, it handles everything transparently as far as I can tell. -=== Fix attribute and method metaclass compatibility +### Fix attribute and method metaclass compatibility So i got this wrong when rewriting it last year - right now, metaclass compat checks the default attribute and method metaclasses, which is wrong. This means @@ -138,34 +139,37 @@ methods that extend existing attributes or methods from a superclass should inherit the metaclass of the existing one. Also not sure if this is correct, but something to think about. -=== Rename a bunch of the public API methods +### Rename a bunch of the public API methods -Right now the public API is kind of a mess - we have things like get_method vs -find_method_by_name (you almost always want to use the latter), there being no -has_method equivalent that checks superclasses, get_method_list being public -but only returning method names, while _get_local_methods is private (returning -method objects), and yet neither of those looks at superclasses, and basically -none of this naming follows any kind of consistent pattern. +Right now the public API is kind of a mess - we have things like `get_method` +vs `find_method_by_name` (you almost always want to use the latter), there +being no `has_method` equivalent that checks superclasses, `get_method_list` +being public but only returning method names, while `_get_local_methods` is +private (returning method objects), and yet neither of those looks at +superclasses, and basically none of this naming follows any kind of consistent +pattern. What we really need is a consistent and easy to remember API where the method that people would think to use first is the method that they actually mean. -Something like renaming find_method_by_name to find_method, and get_method to -find_local_method or something along those lines. +Something like renaming `find_method_by_name` to `find_method`, and `get_method` to +`find_local_method` or something along those lines. -=== use Sub::Identify instead of doing our own thing with get_code_info +### Clean up metaclass constructors -No idea why we stopped using Sub::Identify in the past, but there's no reason -not to do this. We have a bug fix in our version (the isGV_with_GP thing), so -this should be submitted to Sub::Identify first. +There's a _lot_ of different conventions in here. Some things to consider: -=== Move method modifiers out to an external module +* `new` vs `_new` +* allowing new( 'name', %args ) vs ( name => 'name', %args ) +* `Method->wrap` vs `Method->new` + +### Move method modifiers out to an external module Class::Method::Modifiers uses a different method for doing method modifiers, which I'm not sure why we aren't using in Moose right now. Optionally using Class::Method::Modifiers::Fast would be even better - it uses Data::Util to implement XS method modifiers, which could help things a lot. -=== Move type constraints out to an external module +### Move type constraints out to an external module There's nothing about our type constraint system that requires being tied to Moose - it's conceptually an entirely separate system that Moose just happens @@ -173,23 +177,43 @@ to use. Splitting it out into its own thing (that Moose could extend to add things like role types) would make things conceptually a lot cleaner, and would let people interested in just the type system have that. -=== Merge Class::MOP and Moose +### Merge Class::MOP and Moose This is a long term goal, but would allow for a lot of things to be cleaned up. There's a bunch of stuff that's duplicated, and other stuff that's not implemented as well as it could be (Class::MOP::Method::Wrapped should be a role, for instance). +### Fix the error system + +oh god it's terrible -== Things to contemplate +More specifically, we really want exception objects. -=== Does applying metaroles really need to reinitialize the metaclass? +### Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint} + +The Util module has _way_ too much functionality. It needs to be +refactored so it's a thin sugar layer on top of the meta API. As it +stands now, it does things like parse type names (and determine if +they're valid), manage the registry, and much more. + +### Anything with a \_(meta)?class method + +Every method that returns a class name needs to become a rw attribute +that can be set via the constructor. + +## Things to contemplate + +These are ideas we're not sure about. Prototypes are welcome, but we may never +merge the feature. + +### Does applying metaroles really need to reinitialize the metaclass? Seems like the logic that's actually necessary is already contained in -rebless_instance, and not reinitializing means that existing attributes and +`rebless_instance`, and not reinitializing means that existing attributes and methods won't be blown away when metaroles are applied. -=== Do we want to core namespace::autoclean behavior somehow? +### Do we want to core namespace::autoclean behavior somehow? This would add Variable::Magic as a required XS dep (not a huge deal at the moment, since Sub::Name is also a required XS dep, but it'd be nice for Moose @@ -202,236 +226,288 @@ exporters (since those imported methods would be cleaned). If we decide we want this, we may want to core it as an option first ("use Moose -clean" or so), and move to making it the default later. -=== Fix the error system +### Should using -excludes with a role add 'requires' for excluded methods? -oh god it's terrible +It seems to make sense, since otherwise you're violating the role's API +contract. -More specifically, we really want exception objects. +### Moose "strict" mode -=== Should using -excludes with a role add 'requires' for excluded methods? +use Moose 'strict'; This would allow us to have all sort of expensive tests +which can be turned off in prod. -It seems to make sense, since otherwise you're violating the role's API -contract. +### Moose::Philosophy.pod +To explain Moose from a very high level -== Old todo (does anyone look at this?) +### moosedoc -------------------------------------------------------------------------------- -BUGS -------------------------------------------------------------------------------- +We certainly have enough meta-information to make pretty complete POD docs. -------------------------------------------------------------------------------- -FEATURES -------------------------------------------------------------------------------- +## TODO test summary -- DDuncan's Str types +Note that some of these are fairly old, and may not be things we actually want +to do anymore. -subtype 'Str' - => as 'Value' - => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x } - => optimize_as { defined($_[0]) && !ref($_[0]) }; +### `t/basics/basic_class_setup.t` -subtype 'Blob' - => as 'Value' - => where { !Encode::is_utf8( $_[0] ) } - => optimize_as { defined($_[0]) && !ref($_[0]) }; +Imports aren't automatically cleaned. Need to think about bringing +namespace::autoclean functionality into core. -- type unions +### `t/bugs/create_anon_recursion.t` -Add support for doing it with Classes which do not have -a type constraint yet created +Loading Moose::Meta::Class (or probably a lot of other metaclasses) before +loading Moose or Class::MOP causes issues (the bootstrapping gets confused). -- type intersections +### `t/bugs/handles_foreign_class_bug.t` -Mostly just for Roles +There should be a warning when delegated methods override 'new' (and possibly +others?). -- inherited slot specs +### `t/bugs/role_caller.t` -'does' can be added to,.. but not changed -(need type unions for this) +Role methods should be cloned into classes on composition so that using +caller(0) in a role method uses the class's package, not the role's. -- proxy attributes +### `t/cmop/metaclass_incompatibility.t` -a proxied attribute is an attribute -which looks like an attribute, -talks like an attribute, smells -like an attribute,.. but if you -look behind the curtain,.. its -over there.. in that other object +If a child class is created before a parent class, metaclass compatibility +checks won't run on the child when the parent is created, and so the child +could end up with an incompatible metaclass. -(... probably be a custom metaclass) +### `t/cmop/modify_parent_method.t` -- local coerce - -[13:16] mst stevan: slight problem with coerce -[13:16] mst I only get to declare it once -[13:17] mst so if I'm trying to declare it cast-style per-source-class rather than per-target-class -[13:17] mst I am extremely screwed -[13:17] stevan yes -[13:17] stevan they are not class specific -[13:18] stevan they are attached to the type constraint itself -[13:18] * stevan ponders anon-coercion-metaobjects -[13:18] mst yes, that's fine -[13:19] mst but when I declare a class -[13:19] mst I want to be able to say "this class coerces to X type via " -[13:19] stevan yeah something like that -[13:19] stevan oh,.. hmm -[13:20] stevan sort of like inflate/deflate? -[13:20] stevan around the accessors? -[13:25] * bluefeet has quit (Remote host closed the connection) -[13:27] mst no -[13:27] mst nothing like that -[13:27] mst like a cast -[13:31] mst stevan: $obj->foo($bar); where 'foo' expects a 'Foo' object -[13:31] mst stevan: is effectively $bar, right? -[13:32] mst stevan: I want to be able to say in package Bar -[13:32] mst stevan: coerce_to 'Foo' via { ... }; -[13:32] mst etc. -[13:53] stevan hmm - ------------------------------------------------------------ --- Type Constraints refactor ------------------------------------------------------------ - -- add support for locally scoped TC +Modifying parent class methods after a child class has already wrapped them +with a method modifier will cause the child class method to retain the original +method that it wrapped, not the new one it was replaced with. -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). +### `t/immutable/inline_close_over.t` -- look into sugar extensions +Initializers and custom error classes still close over metaobjects. +Initializers do it because the initializer has to be passed in the attribute +metaobject as a parameter, and custom error classes can't be automatically +inlined. -Use roles as sugar layer function providers (ala MooseX::AttributeHelpers). This -would allow custom metaclasses to provide roles to extend the sugar syntax with. +### `t/metaclasses/moose_exporter_trait_aliases.t` -(NOTE: Talk to phaylon a bit more on this) +Renamed imports aren't cleaned on unimport. For instance: -- allow a switch of some kind to optionally turn TC checking off at runtime + package Foo; + use Moose has => { -as => 'my_has' }; + no Moose; + # Foo still contains my_has -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? +### `t/metaclasses/reinitialize.t` -- misc. minor bits +Special method types can't have method metaroles applied. Applying a method +metarole to a class doesn't apply that role to things like constructors, +accessors, etc. -* 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 ... +### `t/roles/compose_overloading.t` -# -# 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]) }; +Overload methods aren't composed during role composition (this is detailed +above - Add overloading support). -# fail() will just return false unless the call is made via -$tc->check_or_fail($value); +### `t/roles/method_modifiers.t` -* and then something like this: +Method modifiers in roles don't support the regex form of method selection. -subtype Foo => as Bar => where { ... } => scoped => -global; -subtype Foo => as Bar => where { ... } => scoped => -local; +### `t/roles/role_compose_requires.t` -# or +Accessors for attributes defined in roles don't satisfy role method +requirements (this is detailed above - Attributes in roles need to be able to +participate in role composition). -subtype Foo => as Bar => where { ... } => in __PACKAGE__ ; +### `t/todo_tests/exception_reflects_failed_constraint.t` -# or (not sure if it would be possible) +Type constraint failures should indicate which ancestor constraint failed - +subtype 'Foo', as 'Str', where { length < 5 } should mention Str when passed an +arrayref, but not when passed the string "ArrayRef". -my $Foo = subtype Bar => where { ... }; +### `t/todo_tests/moose_and_threads.t` -# ---------- +On 5.8, the type constraint name parser isn't thread safe. -[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 +### `t/todo_tests/replacing_super_methods.t` -coerce_deeply => 1 # reads better +Modifying parent class methods after a child class has already wrapped them +with a override will cause 'super' in the child class to call the original +parent class method, not the one it was overridden with. -------------------------------------------------------------------------------- -INTERNALS -------------------------------------------------------------------------------- +### `t/todo_tests/required_role_accessors.t` -- rationalize all the get_X methods for classes (and roles) +Role attribute accessors don't satisfy requires from roles they consume. -We have get_attribute, get_attributes_list, get_all_attributes, -etc. First, we need to make the method names consistent. If something -returns an attribute vs a name, that needs to be clear from the method -name. We also need to make sure that local vs. "entire inheritance -chain" is clear from the name. +### `t/todo_tests/role_insertion_order.t` -This is mostly a CMOP change. +Roles don't preserve attribute `insertion_order`. -- Metaclass constructors +### `t/todo_tests/various_role_features.t` -There's a _lot_ of different conventions in here. Some things to consider: +* Role attribute accessors don't satisfy requires from roles they consume. +* Role combination should produce a conflict when one role has an actual method + and the other role has an accessor. +* Role attribute accessors should not override methods in the class the role is + applied to. +* Role attribute accessors should be delegated when a class does + handles => 'Role'. +* Delegating to a role doesn't make $class->does('Role') true. +* Method modifier in a role doesn't create a method requirement. +* `Role->meta->has_method('attr_accessor')` is false. -* new vs _new -* allowing new( 'name', %args ) vs ( name => 'name', %args ) -* Method->wrap vs Method->new +### `t/type_constraints/type_names.t` -- Moose::Meta::TypeConstraint::Parameter{izable,ized} +Type constraint object constructors don't validate the type name provided. -The relationship between these two classes is very odd. In particular, -this line in Parameterized is insane: +### MooseX::Aliases in core - foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) { +Is there any reason why this would be bad? It would certainly make the +implementation a little faster (it can be inlined better). -Why does it need to loop through all parameterizable types? Shouldn't -it know which parameterizable type it "came from"? +### MooseX::MethodAttributes in core -- Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint} +discuss -The Util module has _way_ too much functionality. It needs to be -refactored so it's a thin sugar layer on top of the meta API. As it -stands now, it does things like parse type names (and determine if -they're valid), manage the registry, and much more. +---- -- Anything with a _(meta)?class method +## Old todo -Every method that returns a class name needs to become a rw attribute -that can be set via the constructor. +Old todo stuff which may be totally out of date. -- The Moose::Error stuff +### DDuncan's Str types -This is sort of half-implemented. We still use Carp directly, and the -internals can't decide how to throw an error (is it -Moose->throw_error, __PACKAGE__->throw_error, what?). + subtype 'Str' + => as 'Value' + => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x } + => optimize_as { defined($_[0]) && !ref($_[0]) }; -The internals need to be made consistent before we expose this to the -rest of the world. + subtype 'Blob' + => as 'Value' + => where { !Encode::is_utf8( $_[0] ) } + => optimize_as { defined($_[0]) && !ref($_[0]) }; -------------------------------------------------------------------------------- -TO PONDER -------------------------------------------------------------------------------- +### type unions -- Moose "strict" mode +Add support for doing it with Classes which do not have a type constraint yet +created -use Moose 'strict'; This would allow us to have all sort of expensive tests -which can be turned off in prod. +### type intersections -- Moose::Philosophy.pod +Mostly just for Roles +KENTNL is working on this -To explain Moose from a very high level +### inherited slot specs -- moosedoc +'does' can be added to,.. but not changed (need type unions for this) -We certainly have enough meta-information to make pretty complete POD docs. +### proxy attributes + +a proxied attribute is an attribute which looks like an attribute, talks like +an attribute, smells like an attribute,.. but if you look behind the +curtain,.. its over there.. in that other object + +(... probably be a custom metaclass) +### local coerce + + [13:16] mst stevan: slight problem with coerce + [13:16] mst I only get to declare it once + [13:17] mst so if I'm trying to declare it cast-style per-source-class rather than per-target-class + [13:17] mst I am extremely screwed + [13:17] stevan yes + [13:17] stevan they are not class specific + [13:18] stevan they are attached to the type constraint itself + [13:18] * stevan ponders anon-coercion-metaobjects + [13:18] mst yes, that's fine + [13:19] mst but when I declare a class + [13:19] mst I want to be able to say "this class coerces to X type via " + [13:19] stevan yeah something like that + [13:19] stevan oh,.. hmm + [13:20] stevan sort of like inflate/deflate? + [13:20] stevan around the accessors? + [13:25] * bluefeet has quit (Remote host closed the connection) + [13:27] mst no + [13:27] mst nothing like that + [13:27] mst like a cast + [13:31] mst stevan: $obj->foo($bar); where 'foo' expects a 'Foo' object + [13:31] mst stevan: is effectively $bar, right? + [13:32] mst stevan: I want to be able to say in package Bar + [13:32] mst stevan: coerce_to 'Foo' via { ... }; + [13:32] mst etc. + [13:53] stevan hmm + +### 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 +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 ... + + 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 + + subtype Foo => as Bar => where { ... } => in __PACKAGE__ ; + + # or (not sure if it would be possible) + + my $Foo = subtype Bar => where { ... }; + +### Deep coercion? + + [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` + +### Moose::Meta::TypeConstraint::Parameter{izable,ized} + +The relationship between these two classes is very odd. In particular, +this line in Parameterized is insane: + + foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) { + +Why does it need to loop through all parameterizable types? Shouldn't +it know which parameterizable type it "came from"?