5 RT#67731 - Union types reports spurious parent types -
6 https://rt.cpan.org/Ticket/Display.html?id=67731
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.
14 RT#69839 - UNIVERSAL methods should show up as methods, so things like method
17 === Revise MetaRole API to reunify class/role metaroles:
24 role_attribute => [ ... ],
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.
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.
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.
41 === Deprecate old-style Moose extensions
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)
48 === Register implicitly created class/role types
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.
56 === Attributes in roles need to be able to participate in role composition
58 Right now, this fails with no decent workaround:
62 has foo => (is => 'ro');
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
79 === Method modifiers in roles should silently add 'requires' for them
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).
86 === Add overloading support
88 or at least, don't break existing overloading support
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.
95 Also, MooseX::Role::WithOverloading should probably be cored.
100 === has +foo in roles
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.
105 === Actual API for metaclass extensions
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.
112 === MooseX::NonMoose in core
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.
121 === Fix attribute and method metaclass compatibility
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.
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.
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.
139 === Rename a bunch of the public API methods
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.
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.
153 === Move load_class and related stuff out to an external module
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
161 === Move method modifiers out to an external module
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.
168 === Move type constraints out to an external module
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.
176 === Merge Class::MOP and Moose
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
184 == Things to contemplate
186 === Does applying metaroles really need to reinitialize the metaclass?
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.
192 === Do we want to core namespace::autoclean behavior somehow?
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).
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.
205 === Fix the error system
209 More specifically, we really want exception objects.
211 === Should using -excludes with a role add 'requires' for excluded methods?
213 It seems to make sense, since otherwise you're violating the role's API
217 == Old todo (does anyone look at this?)
219 -------------------------------------------------------------------------------
221 -------------------------------------------------------------------------------
223 -------------------------------------------------------------------------------
225 -------------------------------------------------------------------------------
227 - DDuncan's Str types
231 => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x }
232 => optimize_as { defined($_[0]) && !ref($_[0]) };
236 => where { !Encode::is_utf8( $_[0] ) }
237 => optimize_as { defined($_[0]) && !ref($_[0]) };
241 Add support for doing it with Classes which do not have
242 a type constraint yet created
246 Mostly just for Roles
248 - inherited slot specs
250 'does' can be added to,.. but not changed
251 (need type unions for this)
255 a proxied attribute is an attribute
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
260 over there.. in that other object
262 (... probably be a custom metaclass)
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
271 [13:17] stevan they are not class specific
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)
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 { ... };
292 -----------------------------------------------------------
293 -- Type Constraints refactor
294 -----------------------------------------------------------
296 - add support for locally scoped TC
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).
303 - look into sugar extensions
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.
308 (NOTE: Talk to phaylon a bit more on this)
310 - allow a switch of some kind to optionally turn TC checking off at runtime
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?
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
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)'))
332 on_fail { MyException->throw(value => $_[0], message => $_[1]) };
334 # fail() will just return false unless the call is made via
335 $tc->check_or_fail($value);
337 * and then something like this:
339 subtype Foo => as Bar => where { ... } => scoped => -global;
340 subtype Foo => as Bar => where { ... } => scoped => -local;
344 subtype Foo => as Bar => where { ... } => in __PACKAGE__ ;
346 # or (not sure if it would be possible)
348 my $Foo = subtype Bar => where { ... };
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
364 coerce_deeply => 1 # reads better
366 -------------------------------------------------------------------------------
368 -------------------------------------------------------------------------------
370 - rationalize all the get_X methods for classes (and roles)
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.
378 This is mostly a CMOP change.
380 - Metaclass constructors
382 There's a _lot_ of different conventions in here. Some things to consider:
385 * allowing new( 'name', %args ) vs ( name => 'name', %args )
386 * Method->wrap vs Method->new
388 - Moose::Meta::TypeConstraint::Parameter{izable,ized}
390 The relationship between these two classes is very odd. In particular,
391 this line in Parameterized is insane:
393 foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) {
395 Why does it need to loop through all parameterizable types? Shouldn't
396 it know which parameterizable type it "came from"?
398 - Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint}
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.
405 - Anything with a _(meta)?class method
407 Every method that returns a class name needs to become a rw attribute
408 that can be set via the constructor.
410 - The Moose::Error stuff
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?).
416 The internals need to be made consistent before we expose this to the
419 -------------------------------------------------------------------------------
421 -------------------------------------------------------------------------------
423 - Moose "strict" mode
425 use Moose 'strict'; This would allow us to have all sort of expensive tests
426 which can be turned off in prod.
428 - Moose::Philosophy.pod
430 To explain Moose from a very high level
434 We certainly have enough meta-information to make pretty complete POD docs.