TODO

   1 == Todo for 2.0400
   2
   3 === RT Tickets
   4
   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
  16
  17 === Register implicitly created class/role types
  18
  19 When you do has foo => (isa => 'Bar'), it returns a class_type for Bar, but
  20 doesn'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
  22 one. We should register the implicitly created ones so that trying to redefine
  23 it after it's used throws an error.
  24
  25 == Todo for 2.0600
  26
  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
  38 If the $meta is a class, we apply the roles to the class. If it's a role, we
  39 hold onto them and apply them as part of applying the role to a class.
  40
  41 To make this all work nicely, we'll probably want to track the original role
  42 where a method was defined, just like we do with attributes currently. We'll
  43 also need to store method modifiers with their original role, which may mean
  44 adding some sort of Moose::Meta::Role::MethodModifier class.
  45
  46 For each role-specific thing (methods, attributes, etc.) we should allow a
  47 role_attribute, role_method, etc. key. The common case will be that the
  48 metaroles are intended for the consuming class, but we should allow for
  49 metaroles on the role's metaobjects as well.
  50
  51 === Deprecate old-style Moose extensions
  52
  53 Moose extensions that work by calling Moose->init_meta(metaclass =>
  54 'Some::Custom::Metaclass', ...) during their own init_meta should be
  55 deprecated, so they can be removed later (this should fix the issues with
  56 init_meta generation in Moose::Exporter, see RT51561)
  57
  58 This needs to wait until the previous fix gets in, since it will hopefully eliminate the need to write custom init_meta methods entirely.
  59
  60 === Attributes in roles need to be able to participate in role composition
  61
  62 Right 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
  77 Role attributes really need to be able to participate in role-role combination.
  78 This should also fix "with 'Role1', 'Role2'" being broken when Role1 implements
  79 a method as an accessor and Role2 requires that method, but at least in that
  80 case you can split it into two 'with' statements with minimal loss of
  81 functionality.
  82
  83 === Method modifiers in roles should silently add 'requires' for them
  84
  85 This shouldn't be a functionality change, just a better error message (and
  86 better introspectability). This shouldn't happen if the role already contains a
  87 method 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
  92 or at least, don't break existing overloading support
  93
  94 This shouldn't treat the overloading stuff as actual methods, since that's just
  95 an implementation detail, but we should provide an API for add_overload,
  96 get_overload, get_overload_list, etc. In particular, this would allow
  97 namespace::autoclean to not break things.
  98
  99 Also, MooseX::Role::WithOverloading should probably be cored.
 100
 101 This should probably also wait for the metarole unification fix, to avoid the
 102 ::WithOverloading stuff being too insane.
 103
 104
 105 == Todo for later
 106
 107 === has +foo in roles
 108
 109 There's no actual reason for this not to work, and it gets asked often enough
 110 that we really should just do it at some point.
 111
 112 === Actual API for metaclass extensions
 113
 114 Right now, the only way to bundle multiple metaclass traits is via
 115 Moose::Exporter. This is unhelpful if you want to apply the extension to a
 116 metaclass object rather than a class you're actually writing. We should come up
 117 with an API for doing this.
 118
 119 === MooseX::NonMoose in core
 120
 121 I think all of the actual issues are solved at this point. The only issue is
 122 the (necessary) implementation weirdness - it sets up multiple inheritance
 123 between the non-Moose class and Moose::Object, and it installs a custom
 124 constructor method at 'extends' time (although perhaps this could be solved by
 125 moving some of the logic back into Moose::Object::new?). Other than that, it
 126 handles everything transparently as far as I can tell.
 127
 128 === Fix attribute and method metaclass compatibility
 129
 130 So i got this wrong when rewriting it last year - right now, metaclass compat
 131 checks the default attribute and method metaclasses, which is wrong. This means
 132 that if a parent class does "use MooseX::FollowPBP", then attributes declared
 133 in a subclass will get PBP-style accessors, which is quite surprising.
 134
 135 On the other hand, sometimes metaclasses might need to be able to say "I'm
 136 going to assume that all of my attributes at least inherit from this custom
 137 class", 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?
 139 I'm not actually sure this is a valid use case though.
 140
 141 Something that probably should be taken into account though is attributes and
 142 methods that extend existing attributes or methods from a superclass should
 143 inherit the metaclass of the existing one. Also not sure if this is correct,
 144 but something to think about.
 145
 146 === Rename a bunch of the public API methods
 147
 148 Right now the public API is kind of a mess - we have things like get_method vs
 149 find_method_by_name (you almost always want to use the latter), there being no
 150 has_method equivalent that checks superclasses, get_method_list being public
 151 but only returning method names, while _get_local_methods is private (returning
 152 method objects), and yet neither of those looks at superclasses, and basically
 153 none of this naming follows any kind of consistent pattern.
 154
 155 What we really need is a consistent and easy to remember API where the method
 156 that people would think to use first is the method that they actually mean.
 157 Something like renaming find_method_by_name to find_method, and get_method to
 158 find_local_method or something along those lines.
 159
 160 === use Sub::Identify instead of doing our own thing with get_code_info
 161
 162 No idea why we stopped using Sub::Identify in the past, but there's no reason
 163 not to do this. We have a bug fix in our version (the isGV_with_GP thing), so
 164 this should be submitted to Sub::Identify first.
 165
 166 === Move method modifiers out to an external module
 167
 168 Class::Method::Modifiers uses a different method for doing method modifiers,
 169 which I'm not sure why we aren't using in Moose right now. Optionally using
 170 Class::Method::Modifiers::Fast would be even better - it uses Data::Util to
 171 implement XS method modifiers, which could help things a lot.
 172
 173 === Move type constraints out to an external module
 174
 175 There's nothing about our type constraint system that requires being tied to
 176 Moose - it's conceptually an entirely separate system that Moose just happens
 177 to use. Splitting it out into its own thing (that Moose could extend to add
 178 things like role types) would make things conceptually a lot cleaner, and would
 179 let people interested in just the type system have that.
 180
 181 === Merge Class::MOP and Moose
 182
 183 This is a long term goal, but would allow for a lot of things to be cleaned up.
 184 There's a bunch of stuff that's duplicated, and other stuff that's not
 185 implemented as well as it could be (Class::MOP::Method::Wrapped should be a
 186 role, for instance).
 187
 188
 189 == Things to contemplate
 190
 191 === Does applying metaroles really need to reinitialize the metaclass?
 192
 193 Seems like the logic that's actually necessary is already contained in
 194 rebless_instance, and not reinitializing means that existing attributes and
 195 methods won't be blown away when metaroles are applied.
 196
 197 === Do we want to core namespace::autoclean behavior somehow?
 198
 199 This would add Variable::Magic as a required XS dep (not a huge deal at the
 200 moment, since Sub::Name is also a required XS dep, but it'd be nice for Moose
 201 to be able to be pure perl again at some point in the future, and I'm not sure
 202 what the relative chances of Sub::Name vs Variable::Magic making it into core
 203 are). If we enabled it by default, this would also break things for people who
 204 have introduced Moose into legacy-ish systems where roles are faked using
 205 exporters (since those imported methods would be cleaned).
 206
 207 If we decide we want this, we may want to core it as an option first ("use
 208 Moose -clean" or so), and move to making it the default later.
 209
 210 === Fix the error system
 211
 212 oh god it's terrible
 213
 214 More specifically, we really want exception objects.
 215
 216 === Should using -excludes with a role add 'requires' for excluded methods?
 217
 218 It seems to make sense, since otherwise you're violating the role's API
 219 contract.
 220
 221
 222 == TODO test summary
 223
 224 Note that some of these are fairly old, and may not be things we actually want
 225 to do anymore.
 226
 227 === t/basics/basic_class_setup.t
 228
 229 Imports aren't automatically cleaned. Need to think about bringing
 230 namespace::autoclean functionality into core.
 231
 232 === t/bugs/create_anon_recursion.t
 233
 234 Loading Moose::Meta::Class (or probably a lot of other metaclasses) before
 235 loading Moose or Class::MOP causes issues (the bootstrapping gets confused).
 236
 237 === t/bugs/handles_foreign_class_bug.t
 238
 239 There should be a warning when delegated methods override 'new' (and possibly
 240 others?).
 241
 242 === t/bugs/role_caller.t
 243
 244 Role methods should be cloned into classes on composition so that using
 245 caller(0) in a role method uses the class's package, not the role's.
 246
 247 === t/cmop/metaclass_incompatibility.t
 248
 249 If a child class is created before a parent class, metaclass compatibility
 250 checks won't run on the child when the parent is created, and so the child
 251 could end up with an incompatible metaclass.
 252
 253 === t/cmop/modify_parent_method.t
 254
 255 Modifying parent class methods after a child class has already wrapped them
 256 with a method modifier will cause the child class method to retain the original
 257 method that it wrapped, not the new one it was replaced with.
 258
 259 === t/immutable/inline_close_over.t
 260
 261 Initializers and custom error classes still close over metaobjects.
 262 Initializers do it because the initializer has to be passed in the attribute
 263 metaobject as a parameter, and custom error classes can't be automatically
 264 inlined.
 265
 266 === t/metaclasses/moose_exporter_trait_aliases.t
 267
 268 Renamed 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
 277 Special method types can't have method metaroles applied. Applying a method
 278 metarole to a class doesn't apply that role to things like constructors,
 279 accessors, etc.
 280
 281 === t/roles/compose_overloading.t
 282
 283 Overload methods aren't composed during role composition (this is detailed
 284 above - Add overloading support).
 285
 286 === t/roles/method_modifiers.t
 287
 288 Method modifiers in roles don't support the regex form of method selection.
 289
 290 === t/roles/role_compose_requires.t
 291
 292 Accessors for attributes defined in roles don't satisfy role method
 293 requirements (this is detailed above - Attributes in roles need to be able to
 294 participate in role composition).
 295
 296 === t/todo_tests/exception_reflects_failed_constraint.t
 297
 298 Type constraint failures should indicate which ancestor constraint failed -
 299 subtype 'Foo', as 'Str', where { length < 5 } should mention Str when passed an
 300 arrayref, but not when passed the string "ArrayRef".
 301
 302 === t/todo_tests/moose_and_threads.t
 303
 304 On 5.8, the type constraint name parser isn't thread safe.
 305
 306 === t/todo_tests/replacing_super_methods.t
 307
 308 Modifying parent class methods after a child class has already wrapped them
 309 with a override will cause 'super' in the child class to call the original
 310 parent class method, not the one it was overridden with.
 311
 312 === t/todo_tests/required_role_accessors.t
 313
 314 Role attribute accessors don't satisfy requires from roles they consume.
 315
 316 === t/todo_tests/role_insertion_order.t
 317
 318 Roles 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
 335 Type constraint object constructors don't validate the type name provided.
 336
 337
 338 == Old todo (does anyone look at this?)
 339
 340 -------------------------------------------------------------------------------
 341 BUGS
 342 -------------------------------------------------------------------------------
 343
 344 -------------------------------------------------------------------------------
 345 FEATURES
 346 -------------------------------------------------------------------------------
 347
 348 - DDuncan's Str types
 349
 350 subtype 'Str'
 351     => as 'Value'
 352     => where { Encode::is_utf8( $_[0] ) or $_[0] !~ m/[^0x00-0x7F]/x }
 353     => optimize_as { defined($_[0]) && !ref($_[0]) };
 354
 355 subtype 'Blob'
 356     => as 'Value'
 357     => where { !Encode::is_utf8( $_[0] ) }
 358     => optimize_as { defined($_[0]) && !ref($_[0]) };
 359
 360 - type unions
 361
 362 Add support for doing it with Classes which do not have
 363 a type constraint yet created
 364
 365 - type intersections
 366
 367 Mostly just for Roles
 368
 369 - inherited slot specs
 370
 371 'does' can be added to,.. but not changed
 372 (need type unions for this)
 373
 374 - proxy attributes
 375
 376 a proxied attribute is an attribute
 377 which looks like an attribute,
 378 talks like an attribute, smells
 379 like an attribute,.. but if you
 380 look behind the curtain,.. its
 381 over there.. in that other object
 382
 383 (... probably be a custom metaclass)
 384
 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
 392 [13:17]         stevan  they are not class specific
 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.
 411 [13:53]         stevan  hmm
 412
 413 -----------------------------------------------------------
 414 -- Type Constraints refactor
 415 -----------------------------------------------------------
 416
 417 - add support for locally scoped TC
 418
 419 This would borrow from MooseX::TypeLibrary to prefix the TC with the name
 420 of the package. It would then be accesible from the outside as the fully
 421 scoped name, but the local attributes would use it first. (this would need support
 422 in the registry for this).
 423
 424 - look into sugar extensions
 425
 426 Use roles as sugar layer function providers (ala MooseX::AttributeHelpers). This
 427 would 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
 433 The type checks can get expensive and some people have suggested that allowing
 434 the checks to be turned off would be helpful for deploying into performance
 435 intensive 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 #
 448 subtype '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         }
 453 on_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
 460 subtype Foo => as Bar => where { ... } => scoped => -global;
 461 subtype Foo => as Bar => where { ... } => scoped => -local;
 462
 463 # or
 464
 465 subtype Foo => as Bar => where { ... } => in __PACKAGE__ ;
 466
 467 # or (not sure if it would be possible)
 468
 469 my $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
 485 coerce_deeply => 1 # reads better
 486
 487 -------------------------------------------------------------------------------
 488 INTERNALS
 489 -------------------------------------------------------------------------------
 490
 491 - rationalize all the get_X methods for classes (and roles)
 492
 493 We have get_attribute, get_attributes_list, get_all_attributes,
 494 etc. First, we need to make the method names consistent. If something
 495 returns an attribute vs a name, that needs to be clear from the method
 496 name. We also need to make sure that local vs. "entire inheritance
 497 chain" is clear from the name.
 498
 499 This is mostly a CMOP change.
 500
 501 - Metaclass constructors
 502
 503 There'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
 509 - Moose::Meta::TypeConstraint::Parameter{izable,ized}
 510
 511 The relationship between these two classes is very odd. In particular,
 512 this line in Parameterized is insane:
 513
 514     foreach my $type (Moose::Util::TypeConstraints::get_all_parameterizable_types()) {
 515
 516 Why does it need to loop through all parameterizable types? Shouldn't
 517 it know which parameterizable type it "came from"?
 518
 519 - Moose::Util::TypeConstraints vs Moose::Meta::Type{Coercion,Constraint}
 520
 521 The Util module has _way_ too much functionality. It needs to be
 522 refactored so it's a thin sugar layer on top of the meta API. As it
 523 stands now, it does things like parse type names (and determine if
 524 they're valid), manage the registry, and much more.
 525
 526 - Anything with a _(meta)?class method
 527
 528 Every method that returns a class name needs to become a rw attribute
 529 that can be set via the constructor.
 530
 531 - The Moose::Error stuff
 532
 533 This is sort of half-implemented. We still use Carp directly, and the
 534 internals can't decide how to throw an error (is it
 535 Moose->throw_error, __PACKAGE__->throw_error, what?).
 536
 537 The internals need to be made consistent before we expose this to the
 538 rest of the world.
 539
 540 -------------------------------------------------------------------------------
 541 TO PONDER
 542 -------------------------------------------------------------------------------
 543
 544 - Moose "strict" mode
 545
 546 use Moose 'strict'; This would allow us to have all sort of expensive tests
 547 which can be turned off in prod.
 548
 549 - Moose::Philosophy.pod
 550
 551 To explain Moose from a very high level
 552
 553 - moosedoc
 554
 555 We certainly have enough meta-information to make pretty complete POD docs.
 556
 557
 558