1 # vim: set ft=markdown :
3 ## Uncontroversial Items
5 These items are reasonably well thought out, and can go in any major release.
9 RT#59478/RT#63000 - 0+ overload causes NV conversion on == on perls before
10 5.14 - this causes comparisons to fail when the number can't fit in an NV
11 without precision loss. I'd like to fix this in a more general way (forcing
12 anyone else who might be using == on tc objects to do weird things isn't very
13 good), although it's hard to test to see what actually works.
15 ### Revise MetaRole API to reunify class/role metaroles:
22 role_attribute => [ ... ],
26 If the $meta is a class, we apply the roles to the class. If it's a role, we
27 hold onto them and apply them as part of applying the role to a class.
29 To make this all work nicely, we'll probably want to track the original role
30 where a method was defined, just like we do with attributes currently. We'll
31 also need to store method modifiers with their original role, which may mean
32 adding some sort of Moose::Meta::Role::MethodModifier class.
34 For each role-specific thing (methods, attributes, etc.) we should allow a
35 `role_attribute`, `role_method`, etc. key. The common case will be that the
36 metaroles are intended for the consuming class, but we should allow for
37 metaroles on the role's metaobjects as well.
39 ### Deprecate old-style Moose extensions
41 Moose extensions that work by calling `Moose->init_meta(metaclass =>
42 'Some::Custom::Metaclass', ...)` during their own `init_meta` should be
43 deprecated, so they can be removed later (this should fix the issues with
44 `init_meta` generation in Moose::Exporter, see RT51561)
46 This needs to wait until the previous fix gets in, since it will hopefully
47 eliminate the need to write custom `init_meta` methods entirely.
49 ### Attributes in roles need to be able to participate in role composition
51 Right now, this fails with no decent workaround:
55 has foo => (is => 'ro');
66 Role attributes really need to be able to participate in role-role combination.
67 This should also fix "with 'Role1', 'Role2'" being broken when Role1 implements
68 a method as an accessor and Role2 requires that method, but at least in that
69 case you can split it into two 'with' statements with minimal loss of
72 ### Method modifiers in roles should silently add 'requires' for them
74 This shouldn't be a functionality change, just a better error message (and
75 better introspectability). This shouldn't happen if the role already contains a
76 method by that name, so it'll depend on the previous fix going in (so "has foo
77 => (is => 'ro'); around foo => sub { }" doesn't produce a 'requires' entry).
81 There's no actual reason for this not to work, and it gets asked often enough
82 that we really should just do it at some point.
84 ### use Sub::Identify instead of doing our own thing with `get_code_info`
86 No idea why we stopped using Sub::Identify in the past, but there's no reason
87 not to do this. We have a bug fix in our version (the `isGV_with_GP` thing), so
88 this should be submitted to Sub::Identify first.
92 These are things we think are good ideas, but they need more fleshing out.
94 ### Add overloading support
96 or at least, don't break existing overloading support
98 This shouldn't treat the overloading stuff as actual methods, since that's just
99 an implementation detail, but we should provide an API for `add_overload`,
100 `get_overload`, `get_overload_list`, etc. In particular, this would allow
101 namespace::autoclean to not break things.
103 Also, MooseX::Role::WithOverloading should probably be cored.
105 This should probably also wait for the metarole unification fix, to avoid the
106 ::WithOverloading stuff being too insane.
108 ### Actual API for metaclass extensions
110 Right now, the only way to bundle multiple metaclass traits is via
111 Moose::Exporter. This is unhelpful if you want to apply the extension to a
112 metaclass object rather than a class you're actually writing. We should come up
113 with an API for doing this.
115 ### MooseX::NonMoose in core
117 I think all of the actual issues are solved at this point. The only issue is
118 the (necessary) implementation weirdness - it sets up multiple inheritance
119 between the non-Moose class and Moose::Object, and it installs a custom
120 constructor method at 'extends' time (although perhaps this could be solved by
121 moving some of the logic back into Moose::Object::new?). Other than that, it
122 handles everything transparently as far as I can tell.
124 ### Fix attribute and method metaclass compatibility
126 So i got this wrong when rewriting it last year - right now, metaclass compat
127 checks the default attribute and method metaclasses, which is wrong. This means
128 that if a parent class does "use MooseX::FollowPBP", then attributes declared
129 in a subclass will get PBP-style accessors, which is quite surprising.
131 On the other hand, sometimes metaclasses might need to be able to say "I'm
132 going to assume that all of my attributes at least inherit from this custom
133 class", so we might need to split it into "default specified by the user" and
134 "default specified by the metaclass" and only do compat checking on the second?
135 I'm not actually sure this is a valid use case though.
137 Something that probably should be taken into account though is attributes and
138 methods that extend existing attributes or methods from a superclass should
139 inherit the metaclass of the existing one. Also not sure if this is correct,
140 but something to think about.
142 ### Rename a bunch of the public API methods
144 Right now the public API is kind of a mess - we have things like `get_method`
145 vs `find_method_by_name` (you almost always want to use the latter), there
146 being no `has_method` equivalent that checks superclasses, `get_method_list`
147 being public but only returning method names, while `_get_local_methods` is
148 private (returning method objects), and yet neither of those looks at
149 superclasses, and basically none of this naming follows any kind of consistent
152 What we really need is a consistent and easy to remember API where the method
153 that people would think to use first is the method that they actually mean.
154 Something like renaming `find_method_by_name` to `find_method`, and `get_method` to
155 `find_local_method` or something along those lines.
157 ### Clean up metaclass constructors
159 There's a _lot_ of different conventions in here. Some things to consider:
162 * allowing new( 'name', %args ) vs ( name => 'name', %args )
163 * `Method->wrap` vs `Method->new`
165 ### Move method modifiers out to an external module
167 Class::Method::Modifiers uses a different method for doing method modifiers,
168 which I'm not sure why we aren't using in Moose right now. Optionally using
169 Class::Method::Modifiers::Fast would be even better - it uses Data::Util to
170 implement XS method modifiers, which could help things a lot.
172 ### Move type constraints out to an external module
174 There's nothing about our type constraint system that requires being tied to
175 Moose - it's conceptually an entirely separate system that Moose just happens
176 to use. Splitting it out into its own thing (that Moose could extend to add
177 things like role types) would make things conceptually a lot cleaner, and would
178 let people interested in just the type system have that.
180 ### Merge Class::MOP and Moose
182 This is a long term goal, but would allow for a lot of things to be cleaned up.
183 There's a bunch of stuff that's duplicated, and other stuff that's not
184 implemented as well as it could be (Class::MOP::Method::Wrapped should be a
187 ### Fix the error system
191 More specifically, we really want exception objects.
193 ### Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint}
195 The Util module has _way_ too much functionality. It needs to be
196 refactored so it's a thin sugar layer on top of the meta API. As it
197 stands now, it does things like parse type names (and determine if
198 they're valid), manage the registry, and much more.
200 ### Anything with a \_(meta)?class method
202 Every method that returns a class name needs to become a rw attribute
203 that can be set via the constructor.
205 ### Make method conflicts in role -> role application silent
207 Right now this becomes a conflict. We should make this simply ignore the
208 applied role's method (consumer wins), just like with classes.
210 Note that this does *not* apply to role summation, where the current behavior
211 (generates a conflict) is correct.
213 ## Things to contemplate
215 These are ideas we're not sure about. Prototypes are welcome, but we may never
218 ### Does applying metaroles really need to reinitialize the metaclass?
220 Seems like the logic that's actually necessary is already contained in
221 `rebless_instance`, and not reinitializing means that existing attributes and
222 methods won't be blown away when metaroles are applied.
224 ### Do we want to core namespace::autoclean behavior somehow?
226 This would add Variable::Magic as a required XS dep (not a huge deal at the
227 moment, since Sub::Name is also a required XS dep, but it'd be nice for Moose
228 to be able to be pure perl again at some point in the future, and I'm not sure
229 what the relative chances of Sub::Name vs Variable::Magic making it into core
230 are). If we enabled it by default, this would also break things for people who
231 have introduced Moose into legacy-ish systems where roles are faked using
232 exporters (since those imported methods would be cleaned).
234 If we decide we want this, we may want to core it as an option first ("use
235 Moose -clean" or so), and move to making it the default later.
237 ### Should using -excludes with a role add 'requires' for excluded methods?
239 It seems to make sense, since otherwise you're violating the role's API
242 ### Moose "strict" mode
244 use Moose 'strict'; This would allow us to have all sort of expensive tests
245 which can be turned off in prod.
247 ### Moose::Philosophy.pod
249 To explain Moose from a very high level
253 We certainly have enough meta-information to make pretty complete POD docs.
257 Note that some of these are fairly old, and may not be things we actually want
260 ### `t/basics/basic_class_setup.t`
262 Imports aren't automatically cleaned. Need to think about bringing
263 namespace::autoclean functionality into core.
265 ### `t/bugs/create_anon_recursion.t`
267 Loading Moose::Meta::Class (or probably a lot of other metaclasses) before
268 loading Moose or Class::MOP causes issues (the bootstrapping gets confused).
270 ### `t/bugs/handles_foreign_class_bug.t`
272 There should be a warning when delegated methods override 'new' (and possibly
275 ### `t/bugs/role_caller.t`
277 Role methods should be cloned into classes on composition so that using
278 caller(0) in a role method uses the class's package, not the role's.
280 ### `t/cmop/metaclass_incompatibility.t`
282 If a child class is created before a parent class, metaclass compatibility
283 checks won't run on the child when the parent is created, and so the child
284 could end up with an incompatible metaclass.
286 ### `t/cmop/modify_parent_method.t`
288 Modifying parent class methods after a child class has already wrapped them
289 with a method modifier will cause the child class method to retain the original
290 method that it wrapped, not the new one it was replaced with.
292 ### `t/immutable/inline_close_over.t`
294 Initializers and custom error classes still close over metaobjects.
295 Initializers do it because the initializer has to be passed in the attribute
296 metaobject as a parameter, and custom error classes can't be automatically
299 ### `t/metaclasses/moose_exporter_trait_aliases.t`
301 Renamed imports aren't cleaned on unimport. For instance:
304 use Moose has => { -as => 'my_has' };
306 # Foo still contains my_has
308 ### `t/metaclasses/reinitialize.t`
310 Special method types can't have method metaroles applied. Applying a method
311 metarole to a class doesn't apply that role to things like constructors,
314 ### `t/roles/compose_overloading.t`
316 Overload methods aren't composed during role composition (this is detailed
317 above - Add overloading support).
319 ### `t/roles/method_modifiers.t`
321 Method modifiers in roles don't support the regex form of method selection.
323 ### `t/roles/role_compose_requires.t`
325 Accessors for attributes defined in roles don't satisfy role method
326 requirements (this is detailed above - Attributes in roles need to be able to
327 participate in role composition).
329 ### `t/todo_tests/exception_reflects_failed_constraint.t`
331 Type constraint failures should indicate which ancestor constraint failed -
332 subtype 'Foo', as 'Str', where { length < 5 } should mention Str when passed an
333 arrayref, but not when passed the string "ArrayRef".
335 ### `t/todo_tests/moose_and_threads.t`
337 On 5.8, the type constraint name parser isn't thread safe.
339 ### `t/todo_tests/replacing_super_methods.t`
341 Modifying parent class methods after a child class has already wrapped them
342 with a override will cause 'super' in the child class to call the original
343 parent class method, not the one it was overridden with.
345 ### `t/todo_tests/required_role_accessors.t`
347 Role attribute accessors don't satisfy requires from roles they consume.
349 ### `t/todo_tests/role_insertion_order.t`
351 Roles don't preserve attribute `insertion_order`.
353 ### `t/todo_tests/various_role_features.t`
355 * Role attribute accessors don't satisfy requires from roles they consume.
356 * Role combination should produce a conflict when one role has an actual method
357 and the other role has an accessor.
358 * Role attribute accessors should not override methods in the class the role is
360 * Role attribute accessors should be delegated when a class does
362 * Delegating to a role doesn't make $class->does('Role') true.
363 * Method modifier in a role doesn't create a method requirement.
364 * `Role->meta->has_method('attr_accessor')` is false.
366 ### `t/type_constraints/type_names.t`
368 Type constraint object constructors don't validate the type name provided.
374 Old todo stuff which may be totally out of date.
376 ### DDuncan's Str types
380 => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x }
381 => optimize_as { defined($_[0]) && !ref($_[0]) };
385 => where { !Encode::is_utf8( $_[0] ) }
386 => optimize_as { defined($_[0]) && !ref($_[0]) };
390 Add support for doing it with Classes which do not have a type constraint yet
393 ### type intersections
395 Mostly just for Roles
397 ### inherited slot specs
399 'does' can be added to,.. but not changed (need type unions for this)
403 a proxied attribute is an attribute which looks like an attribute, talks like
404 an attribute, smells like an attribute,.. but if you look behind the
405 curtain,.. its over there.. in that other object
407 (... probably be a custom metaclass)
411 [13:16] mst stevan: slight problem with coerce
412 [13:16] mst I only get to declare it once
413 [13:17] mst so if I'm trying to declare it cast-style per-source-class rather than per-target-class
414 [13:17] mst I am extremely screwed
416 [13:17] stevan they are not class specific
417 [13:18] stevan they are attached to the type constraint itself
418 [13:18] * stevan ponders anon-coercion-metaobjects
419 [13:18] mst yes, that's fine
420 [13:19] mst but when I declare a class
421 [13:19] mst I want to be able to say "this class coerces to X type via <this>"
422 [13:19] stevan yeah something like that
423 [13:19] stevan oh,.. hmm
424 [13:20] stevan sort of like inflate/deflate?
425 [13:20] stevan around the accessors?
426 [13:25] * bluefeet has quit (Remote host closed the connection)
428 [13:27] mst nothing like that
429 [13:27] mst like a cast
430 [13:31] mst stevan: $obj->foo($bar); where 'foo' expects a 'Foo' object
431 [13:31] mst stevan: is effectively <Foo>$bar, right?
432 [13:32] mst stevan: I want to be able to say in package Bar
433 [13:32] mst stevan: coerce_to 'Foo' via { ... };
437 ### add support for locally scoped TC
439 This would borrow from MooseX::TypeLibrary to prefix the TC with the name
440 of the package. It would then be accesible from the outside as the fully
441 scoped name, but the local attributes would use it first. (this would need support
442 in the registry for this).
444 ### look into sugar extensions
446 Use roles as sugar layer function providers (ala MooseX::AttributeHelpers). This
447 would allow custom metaclasses to provide roles to extend the sugar syntax with.
449 (NOTE: Talk to phaylon a bit more on this)
451 ### allow a switch of some kind to optionally turn TC checking off at runtime
453 The type checks can get expensive and some people have suggested that allowing
454 the checks to be turned off would be helpful for deploying into performance
455 intensive systems. Perhaps this can actually be done as an option to `make_immutable`?
459 * make the errors for TCs use `->message`
460 * look into localizing the messages too
461 * make ANON TCs be lazy, so they can possibly be subsituted for the real thing later
462 * make ANON TCs more introspectable
467 where { (/[a-z][a-z0-9]+/i or fail('Invalid character(s)'))
468 and (length($_) >= 5 or fail('Too short (less than 5 chars)'))
470 on_fail { MyException->throw(value => $_[0], message => $_[1]) };
472 fail() will just return false unless the call is made via `$tc->check_or_fail($value);`
474 * and then something like this:
476 subtype Foo => as Bar => where { ... } => scoped => -global;
477 subtype Foo => as Bar => where { ... } => scoped => -local;
481 subtype Foo => as Bar => where { ... } => in __PACKAGE__ ;
483 # or (not sure if it would be possible)
485 my $Foo = subtype Bar => where { ... };
489 [17:10] <autarch> stevan: it should do it if I pass coerce => 1 as part of the attribute definition
490 [17:12] <stevan> autarch: what I am not 100% sure of is how to tell it to deep coerce and when to not
491 [17:13] <stevan> cause a basic coerce is from A to B
492 [17:13] <autarch> hmm
493 [17:13] <stevan> which is valid for collection types too
494 [17:13] <stevan> deep coercion is what you are asking for
495 [17:13] <autarch> yeah
496 [17:13] <stevan> so perhaps we add deep_coerce => 1
497 [17:13] <stevan> which will do it
498 [17:13] <autarch> that's fine for me
501 `coerce_deeply => 1 # reads better`
503 ### Moose::Meta::TypeConstraint::Parameter{izable,ized}
505 The relationship between these two classes is very odd. In particular,
506 this line in Parameterized is insane:
508 foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) {
510 Why does it need to loop through all parameterizable types? Shouldn't
511 it know which parameterizable type it "came from"?