Time for a rewrite
Just kidding ;-) But there is some truth: 1. MooseX::Declare has gained us a lot of insight on what we can do substantially better 2. We learned how to structure extensibility with traits 3. we got a bunch of stuff wrong (ranging from slightly annoying to oops, sorry) 4. we have probably gotten things wrong that we don't know about Fortunately the MOP api is designed to be extensible, the only unanswered question is what defaults to we ship. I think it's time to start thinking about how to get Perl's 'use 5.010' for Moose, in one form or another. Fortunately, Perl kinda sorts this out for us: use Moose 0.92 qw(foo bar); This will: 1. require Moose 2. call Moose-VERSION(0.92) from the POV of the caller 3. call Moose-import(qw(foo bar)) In terms of infrastructure I think that doesn't take much else, Moose::VERSION will simply init_meta slightly differently, and the import routine can act accordingly (it is already capable of detecting pre-initialized metaclasses). I think if we structure Moose's features in a more plugin like architecture, where the metaclass instance can augment or replace the Moose::Exporter stuff to some extent, it should be trivial to make a future and backwards compatible way to keep things clean. Using a metaclass centered approach we can just let polymorphism ensure we have all our opportunities open. So anyway, I'll reply to myself with what I dislike about Moose in its current form, and I hope you do the same
Re: Time for a rewrite
Hi, Since I'm speaking generally, rather than responding, I hope top posting is considered acceptable. Things I'd like to see done differently (not exactly things I don't like, but just irritate me) 1) See Moose more as a way to hook up a bunch of suger, like MX:Declare, advanced types and exceptions, possible event multi methods and the stuff in Moose::Autobox. 2) So more deep stuff moved to MOP, like Roles (not sure if this is possible, but you said anything :) ) 3) Type constraints decoupled from Moose and some things changed under the hood to make it easier to improve error messages for things like MX:T:Structured and other changes so that slurpy in MX:T:Structured doesn't have to be an evil hack. A stand alone type constraint system that makes it easier for me to complete the dependent and faceted type stuff sitting inthe repo for like a year would be nice. And of course a sweet MooseX::Declare style syntax. Then we can end the stringy types versus MooseX::Types style types issue for good. 4) Lispy conditionals (I know it's been said before, but I think we are closer now to making this workable) - Original Message From: Yuval Kogman nothingm...@woobling.org To: moose@perl.org Sent: Tue, November 10, 2009 2:49:44 PM Subject: Time for a rewrite Just kidding ;-) But there is some truth: 1. MooseX::Declare has gained us a lot of insight on what we can do substantially better 2. We learned how to structure extensibility with traits 3. we got a bunch of stuff wrong (ranging from slightly annoying to oops, sorry) 4. we have probably gotten things wrong that we don't know about Fortunately the MOP api is designed to be extensible, the only unanswered question is what defaults to we ship. I think it's time to start thinking about how to get Perl's 'use 5.010' for Moose, in one form or another. Fortunately, Perl kinda sorts this out for us: use Moose 0.92 qw(foo bar); This will: 1. require Moose 2. call Moose-VERSION(0.92) from the POV of the caller 3. call Moose-import(qw(foo bar)) In terms of infrastructure I think that doesn't take much else, Moose::VERSION will simply init_meta slightly differently, and the import routine can act accordingly (it is already capable of detecting pre-initialized metaclasses). I think if we structure Moose's features in a more plugin like architecture, where the metaclass instance can augment or replace the Moose::Exporter stuff to some extent, it should be trivial to make a future and backwards compatible way to keep things clean. Using a metaclass centered approach we can just let polymorphism ensure we have all our opportunities open. So anyway, I'll reply to myself with what I dislike about Moose in its current form, and I hope you do the same
Re: Time for a rewrite
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.
Re: Time for a rewrite
Let's please focus on things that are wrong and need fixing first, not things that we might like to have in some fancy future moose.
Re: Time for a rewrite
To clarify, this is not an RFC on how to improve Moose. We are already doing that, it's called MooseX and it's doing the job just fine. As always, after a feature is fleshed out a feature as a MooseX module we decide on whether or not to include it. If you want to propose a feature, do it that way =) I'm talking about the other half of progress, letting go of past mistakes in a way that allows us to do the first part more easily and more dramatically, without hurting existing code in the ecosystem. The points that John raised are all either existing MX or potential MX that are simply too much trouble to code right not because they propose doing something radically different, but that's no excuse for not trying them out as extensions beforehand. The problem is simply that right now extensions need work along side lots of baggage, and that's difficult.
Re: Time for a rewrite
2009/11/10 Yuval Kogman nothingm...@woobling.org 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 i guess i saw a balloon or something. if we find a way to make it clear when we invoke specific callbacks and what they can do, perhaps we can consolidate this with initializers, or maybe even the type checks/coercions
Re: Time for a rewrite
I've always liked the interaction between lazy and clear, clear resets the slot. That makes sense. The rest of it is all great. Trigger and Initializer were so confusing for me personally that I had to write specific notes about them. http://en.wikibooks.org/wiki/Programming_with_Moose/Syntax/has#Clearing_up_confusion Also, for when lazy is not enough, sometimes I want control over the initialization order within the same module. I was playing around with role yesterday and iirc correctly I found something surprising, I couldn't do. I thought that `with` specified the order so a role could define an attribute in a role, that a class could override with '+', that didn't work. (If I recall correctly). Roles also have open bugs that breaks the interface part, (requires() isn't working in the newest moose at all, forcing you to remove the pragma because it always throws an exception on moose-attributes). -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
