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