Oh, and maybe a way to have a type-constraint fire once without
testing for failure as was the behavoir pre .76. That broke probably
50% of my MooseX::Types code. I still regress my Mooses to remove this
behavoir. Sure, it might make more sense, but testing to see if you
have spaces on a string jus
On Tue, Nov 10, 2009 at 03:37:54PM -0600, Jesse Luehrs wrote:
> 1) Attributes in roles aren't real objects, and there is no attribute
> metaclass for roles. This makes it impossible to automatically apply
> attribute traits through ::MetaRole.
>
> 2) Metaclass compatibility code in Moose/CMOP is p
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#
1) Attributes in roles aren't real objects, and there is no attribute
metaclass for roles. This makes it impossible to automatically apply
attribute traits through ::MetaRole.
2) Metaclass compatibility code in Moose/CMOP is pretty broken. It
happens to work reasonably in most cases because it can
2009/11/10 Yuval Kogman
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
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
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 fin
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.
> 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 make
gt; From: Yuval Kogman
> 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
>
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
11 matches
Mail list logo
