topic/attribute-controls-storage

2009-11-10 Thread Nathan Gass
Hello The code/branch I talk about lives at http://github.com/xabbu42/class-mop/tree/topic/attribute-controls-storage and http://github.com/xabbu42/moose/tree/topic/attribute-controls-storage As discussed in the thread MooseX::Attribute::Delegated I created a topic branch

Time for a rewrite

2009-11-10 Thread Yuval Kogman
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

Re: Time for a rewrite

2009-11-10 Thread John Napiorkowski
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

Re: Time for a rewrite

2009-11-10 Thread Yuval Kogman
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

Re: Time for a rewrite

2009-11-10 Thread Yuval Kogman
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

2009-11-10 Thread Yuval Kogman
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

Re: Time for a rewrite

2009-11-10 Thread Yuval Kogman
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

Re: Time for a rewrite

2009-11-10 Thread Evan Carroll
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.

Re: Some newb questions

2009-11-10 Thread Chris Prather
On Tue, Nov 10, 2009 at 6:09 PM, Markx.Allen markx.al...@target.com wrote: I've read through almost all of the Moose docs I could find on CPAN and several of the Moose slide decks floating around the Interwebs. That being said I have some basic questions that probably have simple answers.  

Re: topic/attribute-controls-storage

2009-11-10 Thread Nathan Gass
On Monday 09 November 2009 23:54:07 Stevan Little wrote: On Nov 9, 2009, at 5:42 PM, Jesse Luehrs wrote: On Mon, Nov 09, 2009 at 05:26:17PM -0500, Stevan Little wrote: Can you detail more what this change is and why? Best I can tell from the other thread and the github commit views was

Hooking a gettor using a Trait

2009-11-10 Thread roger bush
The following doesn't work. The idea is to add a 'Cached' trait by calling the default 'clearer' routine on an attribute. The reason it doesn't work is that when it is invoked, there is no clearer routine. The code dies with the stack trace saying it doesn't exist on the object (the attribute).