X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=TODO;h=545760039601e94409bd6a32b07aa0bc0d4289d7;hb=7fb4b360f565be7d6dc40c4b2f0d9fc0f6263bc7;hp=e5bc34ff5ecc2503ce07117973a56f7d650e4bac;hpb=687e52bbbeea9c3096697e66aa88c2f022ed7478;p=gitmo%2FMoose.git diff --git a/TODO b/TODO index e5bc34f..5457600 100644 --- a/TODO +++ b/TODO @@ -1,16 +1,60 @@ +== Todo for 2.0200 + +=== Revise MetaRole API to reunify class/role metaroles: + + 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. + +To make this all work nicely, we'll probably want to track the original role +where a method was defined, just like we do with attributes currently. We'll +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 +metaroles are intended for the consuming class, but we should allow for +metaroles on the role's metaobjects as well. + +=== Remove a bunch of deprecated crap + +See Moose::Manual::Delta for a list. Some of this is important to make merging +Class::MOP into Moose core much easier. Other is just removing complexity +needed to support ancient APIs. + +== Old todo (does anyone look at this?) + ------------------------------------------------------------------------------- -TODO +BUGS ------------------------------------------------------------------------------- -- make way to iterate over all Moose classes +------------------------------------------------------------------------------- +FEATURES +------------------------------------------------------------------------------- -- roles +- DDuncan's Str types -Need to figure out the details of composite roles +subtype 'Str' + => as 'Value' + => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x } + => optimize_as { defined($_[0]) && !ref($_[0]) }; + +subtype 'Blob' + => as 'Value' + => where { !Encode::is_utf8( $_[0] ) } + => optimize_as { defined($_[0]) && !ref($_[0]) }; - type unions -Add support for doing it with Classes which do not have +Add support for doing it with Classes which do not have a type constraint yet created - type intersections @@ -19,48 +63,174 @@ Mostly just for Roles - inherited slot specs -[10:49] stevan does can be added to,.. but not changed +'does' can be added to,.. but not changed +(need type unions for this) -- triggers +- proxy attributes -[18:18] mst what I'd really like is just to say trigger => 'some_method' +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 + +----------------------------------------------------------- +-- Type Constraints refactor +----------------------------------------------------------- + +- 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 ... + +# +# 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 + +subtype Foo => as Bar => where { ... } => in __PACKAGE__ ; + +# or (not sure if it would be possible) + +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 -- attribute delgates +------------------------------------------------------------------------------- +INTERNALS +------------------------------------------------------------------------------- -Introduce capability to control the generated wrapper. Useful for when you have -a wrapper that should implement the interface of it's child, but decorate with -more metadata. +- rationalize all the get_X methods for classes (and roles) -- proxy attributes +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. + +This is mostly a CMOP change. + +- Metaclass constructors + +There's a _lot_ of different conventions in here. Some things to consider: + +* new vs _new +* allowing new( 'name', %args ) vs ( name => 'name', %args ) +* Method->wrap vs Method->new + +- Moose::Meta::TypeConstraint::Parameter{izable,ized} -[15:49] stevan you want a proxied attribute -[15:49] stevan 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 +The relationship between these two classes is very odd. In particular, +this line in Parameterized is insane: -- compile time extends + foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) { -[00:39] sri but maybe a better syntax for compile time extends -[00:39] stevan I have been pondering that actually -[00:39] sri use Moose extends => Foo::Bar -[00:40] stevan I think now that we have the Sub::Exporter stuff - in, that kinda thing should be pretty easy +Why does it need to loop through all parameterizable types? Shouldn't +it know which parameterizable type it "came from"? -nothingmuch notes that all the constructs should be supported in the entirety of the use clause: +- Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint} - use Moose ( - has => foo ( - .... - ), - ); +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. -and that if this usage style is used nothing is exported to the namespace. +- Anything with a _(meta)?class method -- default should dclone() +Every method that returns a class name needs to become a rw attribute +that can be set via the constructor. -- auto_deref => 1 for auto-de-refing ARRAY and HASH attrs +- The Moose::Error stuff + +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?). + +The internals need to be made consistent before we expose this to the +rest of the world. ------------------------------------------------------------------------------- TO PONDER @@ -69,8 +239,8 @@ TO PONDER - Moose "strict" mode use Moose 'strict'; This would allow us to have all sort of expensive tests -which can be turned off in prod. - +which can be turned off in prod. + - Moose::Philosophy.pod To explain Moose from a very high level @@ -78,6 +248,6 @@ To explain Moose from a very high level - moosedoc We certainly have enough meta-information to make pretty complete POD docs. - - - + + +