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