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