Commit | Line | Data |
ea8e79f1 |
1 | # vim: set ft=markdown : |
2 | |
6e6a1027 |
3 | ## Uncontroversial Items |
85910734 |
4 | |
6e6a1027 |
5 | These items are reasonably well thought out, and can go in any major release. |
6 | |
7 | ### RT Tickets |
1b1eb1ca |
8 | |
c78a59d7 |
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. |
14 | |
6e6a1027 |
15 | ### Revise MetaRole API to reunify class/role metaroles: |
85910734 |
16 | |
6e6a1027 |
17 | apply_metaroles( |
18 | for => $meta, |
19 | roles => { |
20 | attribute => [...], |
21 | class => [...], |
22 | role_attribute => [ ... ], |
23 | } |
24 | ); |
85910734 |
25 | |
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. |
28 | |
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. |
33 | |
34 | For each role-specific thing (methods, attributes, etc.) we should allow a |
6e6a1027 |
35 | `role_attribute`, `role_method`, etc. key. The common case will be that the |
85910734 |
36 | metaroles are intended for the consuming class, but we should allow for |
37 | metaroles on the role's metaobjects as well. |
38 | |
6e6a1027 |
39 | ### Deprecate old-style Moose extensions |
ef0801e7 |
40 | |
6e6a1027 |
41 | Moose extensions that work by calling `Moose->init_meta(metaclass => |
ea8e79f1 |
42 | 'Some::Custom::Metaclass', ...)` during their own `init_meta` should be |
ef0801e7 |
43 | deprecated, so they can be removed later (this should fix the issues with |
6e6a1027 |
44 | `init_meta` generation in Moose::Exporter, see RT51561) |
ef0801e7 |
45 | |
6e6a1027 |
46 | This needs to wait until the previous fix gets in, since it will hopefully |
ea8e79f1 |
47 | eliminate the need to write custom `init_meta` methods entirely. |
d8fed7e3 |
48 | |
6e6a1027 |
49 | ### Attributes in roles need to be able to participate in role composition |
24b9aca7 |
50 | |
51 | Right now, this fails with no decent workaround: |
52 | |
6e6a1027 |
53 | package R1; |
54 | use Moose::Role; |
55 | has foo => (is => 'ro'); |
24b9aca7 |
56 | |
6e6a1027 |
57 | package R2; |
58 | use Moose::Role; |
59 | with 'R1'; |
60 | requires 'foo'; |
24b9aca7 |
61 | |
6e6a1027 |
62 | package C; |
63 | use Moose; |
64 | with 'R2'; |
24b9aca7 |
65 | |
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 |
70 | functionality. |
71 | |
6e6a1027 |
72 | ### Method modifiers in roles should silently add 'requires' for them |
24b9aca7 |
73 | |
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). |
78 | |
6e6a1027 |
79 | ### has +foo in roles |
80 | |
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. |
83 | |
ea8e79f1 |
84 | ### use Sub::Identify instead of doing our own thing with `get_code_info` |
6e6a1027 |
85 | |
86 | No idea why we stopped using Sub::Identify in the past, but there's no reason |
ea8e79f1 |
87 | not to do this. We have a bug fix in our version (the `isGV_with_GP` thing), so |
6e6a1027 |
88 | this should be submitted to Sub::Identify first. |
89 | |
90 | ## Needs Thought |
91 | |
92 | These are things we think are good ideas, but they need more fleshing out. |
93 | |
94 | ### Add overloading support |
24b9aca7 |
95 | |
96 | or at least, don't break existing overloading support |
97 | |
98 | This shouldn't treat the overloading stuff as actual methods, since that's just |
ea8e79f1 |
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 |
24b9aca7 |
101 | namespace::autoclean to not break things. |
102 | |
103 | Also, MooseX::Role::WithOverloading should probably be cored. |
104 | |
d8fed7e3 |
105 | This should probably also wait for the metarole unification fix, to avoid the |
106 | ::WithOverloading stuff being too insane. |
107 | |
6e6a1027 |
108 | ### Actual API for metaclass extensions |
24b9aca7 |
109 | |
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. |
114 | |
6e6a1027 |
115 | ### MooseX::NonMoose in core |
24b9aca7 |
116 | |
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. |
123 | |
6e6a1027 |
124 | ### Fix attribute and method metaclass compatibility |
24b9aca7 |
125 | |
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. |
130 | |
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. |
136 | |
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. |
141 | |
6e6a1027 |
142 | ### Rename a bunch of the public API methods |
24b9aca7 |
143 | |
6e6a1027 |
144 | Right now the public API is kind of a mess - we have things like `get_method` |
ea8e79f1 |
145 | vs `find_method_by_name` (you almost always want to use the latter), there |
6e6a1027 |
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 |
150 | pattern. |
24b9aca7 |
151 | |
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. |
6e6a1027 |
154 | Something like renaming `find_method_by_name` to `find_method`, and `get_method` to |
155 | `find_local_method` or something along those lines. |
24b9aca7 |
156 | |
6e6a1027 |
157 | ### Clean up metaclass constructors |
6ddfb832 |
158 | |
6e6a1027 |
159 | There's a _lot_ of different conventions in here. Some things to consider: |
6ddfb832 |
160 | |
ea8e79f1 |
161 | * `new` vs `_new` |
6e6a1027 |
162 | * allowing new( 'name', %args ) vs ( name => 'name', %args ) |
ea8e79f1 |
163 | * `Method->wrap` vs `Method->new` |
6e6a1027 |
164 | |
165 | ### Move method modifiers out to an external module |
c762df57 |
166 | |
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. |
171 | |
6e6a1027 |
172 | ### Move type constraints out to an external module |
c762df57 |
173 | |
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. |
179 | |
6e6a1027 |
180 | ### Merge Class::MOP and Moose |
c762df57 |
181 | |
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 |
185 | role, for instance). |
186 | |
6e6a1027 |
187 | ### Fix the error system |
188 | |
189 | oh god it's terrible |
190 | |
191 | More specifically, we really want exception objects. |
192 | |
193 | ### Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint} |
194 | |
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. |
199 | |
ea8e79f1 |
200 | ### Anything with a \_(meta)?class method |
6e6a1027 |
201 | |
202 | Every method that returns a class name needs to become a rw attribute |
203 | that can be set via the constructor. |
204 | |
1c76bb0e |
205 | ### Make method conflicts in role -> role application silent |
206 | |
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. |
209 | |
210 | Note that this does *not* apply to role summation, where the current behavior |
211 | (generates a conflict) is correct. |
212 | |
6e6a1027 |
213 | ## Things to contemplate |
24b9aca7 |
214 | |
6e6a1027 |
215 | These are ideas we're not sure about. Prototypes are welcome, but we may never |
216 | merge the feature. |
24b9aca7 |
217 | |
6e6a1027 |
218 | ### Does applying metaroles really need to reinitialize the metaclass? |
24b9aca7 |
219 | |
220 | Seems like the logic that's actually necessary is already contained in |
ea8e79f1 |
221 | `rebless_instance`, and not reinitializing means that existing attributes and |
24b9aca7 |
222 | methods won't be blown away when metaroles are applied. |
223 | |
6e6a1027 |
224 | ### Do we want to core namespace::autoclean behavior somehow? |
24b9aca7 |
225 | |
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). |
233 | |
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. |
236 | |
6e6a1027 |
237 | ### Should using -excludes with a role add 'requires' for excluded methods? |
24b9aca7 |
238 | |
6e6a1027 |
239 | It seems to make sense, since otherwise you're violating the role's API |
240 | contract. |
24b9aca7 |
241 | |
6e6a1027 |
242 | ### Moose "strict" mode |
24b9aca7 |
243 | |
6e6a1027 |
244 | use Moose 'strict'; This would allow us to have all sort of expensive tests |
245 | which can be turned off in prod. |
24b9aca7 |
246 | |
6e6a1027 |
247 | ### Moose::Philosophy.pod |
248 | |
249 | To explain Moose from a very high level |
250 | |
251 | ### moosedoc |
24b9aca7 |
252 | |
6e6a1027 |
253 | We certainly have enough meta-information to make pretty complete POD docs. |
24b9aca7 |
254 | |
6e6a1027 |
255 | ## TODO test summary |
98fb200c |
256 | |
257 | Note that some of these are fairly old, and may not be things we actually want |
258 | to do anymore. |
259 | |
6e6a1027 |
260 | ### `t/basics/basic_class_setup.t` |
98fb200c |
261 | |
262 | Imports aren't automatically cleaned. Need to think about bringing |
263 | namespace::autoclean functionality into core. |
264 | |
6e6a1027 |
265 | ### `t/bugs/create_anon_recursion.t` |
98fb200c |
266 | |
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). |
269 | |
6e6a1027 |
270 | ### `t/bugs/handles_foreign_class_bug.t` |
98fb200c |
271 | |
272 | There should be a warning when delegated methods override 'new' (and possibly |
273 | others?). |
274 | |
6e6a1027 |
275 | ### `t/bugs/role_caller.t` |
98fb200c |
276 | |
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. |
279 | |
6e6a1027 |
280 | ### `t/cmop/metaclass_incompatibility.t` |
98fb200c |
281 | |
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. |
285 | |
6e6a1027 |
286 | ### `t/cmop/modify_parent_method.t` |
98fb200c |
287 | |
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. |
291 | |
6e6a1027 |
292 | ### `t/immutable/inline_close_over.t` |
98fb200c |
293 | |
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 |
297 | inlined. |
298 | |
6e6a1027 |
299 | ### `t/metaclasses/moose_exporter_trait_aliases.t` |
98fb200c |
300 | |
301 | Renamed imports aren't cleaned on unimport. For instance: |
302 | |
6e6a1027 |
303 | package Foo; |
304 | use Moose has => { -as => 'my_has' }; |
305 | no Moose; |
306 | # Foo still contains my_has |
98fb200c |
307 | |
6e6a1027 |
308 | ### `t/metaclasses/reinitialize.t` |
98fb200c |
309 | |
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, |
312 | accessors, etc. |
313 | |
6e6a1027 |
314 | ### `t/roles/compose_overloading.t` |
98fb200c |
315 | |
316 | Overload methods aren't composed during role composition (this is detailed |
317 | above - Add overloading support). |
318 | |
6e6a1027 |
319 | ### `t/roles/method_modifiers.t` |
98fb200c |
320 | |
321 | Method modifiers in roles don't support the regex form of method selection. |
322 | |
6e6a1027 |
323 | ### `t/roles/role_compose_requires.t` |
98fb200c |
324 | |
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). |
328 | |
6e6a1027 |
329 | ### `t/todo_tests/exception_reflects_failed_constraint.t` |
98fb200c |
330 | |
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". |
334 | |
6e6a1027 |
335 | ### `t/todo_tests/moose_and_threads.t` |
98fb200c |
336 | |
337 | On 5.8, the type constraint name parser isn't thread safe. |
338 | |
6e6a1027 |
339 | ### `t/todo_tests/replacing_super_methods.t` |
98fb200c |
340 | |
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. |
344 | |
6e6a1027 |
345 | ### `t/todo_tests/required_role_accessors.t` |
98fb200c |
346 | |
347 | Role attribute accessors don't satisfy requires from roles they consume. |
348 | |
6e6a1027 |
349 | ### `t/todo_tests/role_insertion_order.t` |
98fb200c |
350 | |
ea8e79f1 |
351 | Roles don't preserve attribute `insertion_order`. |
98fb200c |
352 | |
6e6a1027 |
353 | ### `t/todo_tests/various_role_features.t` |
98fb200c |
354 | |
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 |
359 | applied to. |
360 | * Role attribute accessors should be delegated when a class does |
361 | handles => 'Role'. |
362 | * Delegating to a role doesn't make $class->does('Role') true. |
363 | * Method modifier in a role doesn't create a method requirement. |
ea8e79f1 |
364 | * `Role->meta->has_method('attr_accessor')` is false. |
98fb200c |
365 | |
6e6a1027 |
366 | ### `t/type_constraints/type_names.t` |
98fb200c |
367 | |
368 | Type constraint object constructors don't validate the type name provided. |
369 | |
6e6a1027 |
370 | ---- |
98fb200c |
371 | |
6e6a1027 |
372 | ## Old todo |
43d599e5 |
373 | |
6e6a1027 |
374 | Old todo stuff which may be totally out of date. |
8b59f8d6 |
375 | |
6e6a1027 |
376 | ### DDuncan's Str types |
d4967760 |
377 | |
6e6a1027 |
378 | subtype 'Str' |
379 | => as 'Value' |
380 | => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x } |
381 | => optimize_as { defined($_[0]) && !ref($_[0]) }; |
d4967760 |
382 | |
6e6a1027 |
383 | subtype 'Blob' |
384 | => as 'Value' |
385 | => where { !Encode::is_utf8( $_[0] ) } |
386 | => optimize_as { defined($_[0]) && !ref($_[0]) }; |
d4967760 |
387 | |
6e6a1027 |
388 | ### type unions |
8b59f8d6 |
389 | |
6e6a1027 |
390 | Add support for doing it with Classes which do not have a type constraint yet |
391 | created |
8b59f8d6 |
392 | |
6e6a1027 |
393 | ### type intersections |
8b59f8d6 |
394 | |
395 | Mostly just for Roles |
396 | |
6e6a1027 |
397 | ### inherited slot specs |
8b59f8d6 |
398 | |
6e6a1027 |
399 | 'does' can be added to,.. but not changed (need type unions for this) |
8b59f8d6 |
400 | |
6e6a1027 |
401 | ### proxy attributes |
8b59f8d6 |
402 | |
6e6a1027 |
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 |
db1ab48d |
406 | |
407 | (... probably be a custom metaclass) |
8b59f8d6 |
408 | |
6e6a1027 |
409 | ### local coerce |
410 | |
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 |
415 | [13:17] stevan yes |
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) |
427 | [13:27] mst no |
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 { ... }; |
434 | [13:32] mst etc. |
435 | [13:53] stevan hmm |
436 | |
437 | ### add support for locally scoped TC |
f3dc2e80 |
438 | |
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). |
443 | |
6e6a1027 |
444 | ### look into sugar extensions |
f3dc2e80 |
445 | |
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. |
448 | |
449 | (NOTE: Talk to phaylon a bit more on this) |
450 | |
6e6a1027 |
451 | ### allow a switch of some kind to optionally turn TC checking off at runtime |
f3dc2e80 |
452 | |
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 |
ea8e79f1 |
455 | intensive systems. Perhaps this can actually be done as an option to `make_immutable`? |
f3dc2e80 |
456 | |
6e6a1027 |
457 | ### misc. minor bits |
f3dc2e80 |
458 | |
ea8e79f1 |
459 | * make the errors for TCs use `->message` |
f3dc2e80 |
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 |
463 | * add this ... |
464 | |
6e6a1027 |
465 | subtype 'Username', |
466 | from 'Str', |
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)')) |
469 | } |
470 | on_fail { MyException->throw(value => $_[0], message => $_[1]) }; |
f3dc2e80 |
471 | |
ea8e79f1 |
472 | fail() will just return false unless the call is made via `$tc->check_or_fail($value);` |
f3dc2e80 |
473 | |
474 | * and then something like this: |
475 | |
6e6a1027 |
476 | subtype Foo => as Bar => where { ... } => scoped => -global; |
477 | subtype Foo => as Bar => where { ... } => scoped => -local; |
f3dc2e80 |
478 | |
6e6a1027 |
479 | # or |
f3dc2e80 |
480 | |
6e6a1027 |
481 | subtype Foo => as Bar => where { ... } => in __PACKAGE__ ; |
f3dc2e80 |
482 | |
6e6a1027 |
483 | # or (not sure if it would be possible) |
f3dc2e80 |
484 | |
6e6a1027 |
485 | my $Foo = subtype Bar => where { ... }; |
f3dc2e80 |
486 | |
6e6a1027 |
487 | ### Deep coercion? |
f3dc2e80 |
488 | |
6e6a1027 |
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 |
499 | [17:13] <stevan> k |
f3dc2e80 |
500 | |
ea8e79f1 |
501 | `coerce_deeply => 1 # reads better` |
f3dc2e80 |
502 | |
6e6a1027 |
503 | ### Moose::Meta::TypeConstraint::Parameter{izable,ized} |
7af2c1d2 |
504 | |
505 | The relationship between these two classes is very odd. In particular, |
506 | this line in Parameterized is insane: |
507 | |
508 | foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) { |
509 | |
510 | Why does it need to loop through all parameterizable types? Shouldn't |
511 | it know which parameterizable type it "came from"? |