So anyway, here is my personal shitlist, all of these are backwards
incompatible changes:
1. few people understand when 'trigger' is fired, it could use a rethink
(either make it *every* time something is set, or make 3 separate triggers,
for accessors, constructors, and default values). If we find a way
2. there are features which grew organically which are very complicated to
explain, for instance the interaction between default/builder and lazy
attributes. i think there's room to change the semantics in subtle backwards
incompatible ways if it can help to simplify the implementation and
documentation.
3. the type constraint registry can be deprecated as far as I'm concerned,
all we need is string support for class_type and role_type IMHO, so that the
only valid values for TC parameters are those and type handles (either
MX::Types decorators or typeconstraint objects, but that too can be
simplified)
4. i'd like to see roles split up into pure roles and things that are more
like mixins. Things like 'around' modifiers and even attribute declaration
are currently order sensitive. This can be very useful, for plugins, for
runtime role application, and other things that alter a class, but I think
that the other use case, namely a safer alternative to MI for code reuse
suffers a bit. Having two separate concepts with similar composition rules,
but where one is strict and simple (and therefore limited), and the other is
more perlish (enough rope and all that) would resolve this tension.
5. THE CODE GEN I HATES IT OMG OMG I HATES IT SO MUCH. Unfortunately I've
tried time and time again to rewrite it and failed. It's just too painful.
Figuring out which features make it unreasonably hard to redo the codegen
(i've since forgotten most of the annoying details) might prompt some small
changes which would help this. If we don't strictly need the backwards
compatibility then we could have a much easier time finally delivering on
Moose::XS, MooseX::{Antlers,Compile}, and all of that shiny.
Furthermore, some MooseX modules rely on the current implementation details
and would break badly if they changed.
Using an explicit versioning model we could code freeze the current code,
and do a ground up rewrite that just needs to pass the test. Opting in to
backwards incompatibility gives us lots of freedom in that regard.
7. lazy/clearer
8. Moose is big. I'm not talking about the dist size, I'm talking about the
number of components. If we can simplify the structure of things you get
when you use Moose 2.0 then that would be easier to hack and debug.
9. Lastly, the splitups needed to pull this off would let us implement core
features more like we implement MooseX modules, whose development model has
IMHO lead to much of Moose's success. Being able to have a quick turnaround,
good composability and the ability to back out of failures is something that
MooseX modules enjoy but Moose core does not as much.
