[Catalyst-dev] Moose port progress report

John Napiorkowski jjn1056 at yahoo.com
Mon Mar 31 15:21:35 BST 2008


--- Guillermo Roditi <groditi at gmail.com> wrote:

> First of all, thanks to everyone who has contributed
> ideas, has helped
> me when I have questions, etc.
> 
> I finished porting over the Engines yesterday. All
> the tests pass, but
> I had to modify some of the tests. marcus, mst,
> jrockway, konobi--and
> anyone else who pitched in--I owe you all a beer.
> Now, the Engines are
> ported, I think every single instance of ->NEXT::*
> is gone from the
> codebase and the tests all pass.
> 
> Recent changes:
> 
> I edited the Engines and re-wrote little pieces of
> the code while I
> was there to be slightly more efficient. I don't
> really think a lot of
> these changes will actually make a noticeable
> difference, but hey, why
> not. The changes can all be ported back to the main
> tree very easily
> since none of it has Moose-y bits. If anyone thinks
> it's worth it
> please go ahead and do it. More than anything
> really, there was
> sections of code that could have been rewritten to
> be a lot more
> concise. I think the bits I changed look better now
> and are more
> readable, the 30 or so sub calls I shaved off a
> request are not likely
> to even be noticeable under a profiler.
> 
> General thoughts:
> 
> Applying plugins as roles should now JustWork. I
> think using roles and
> method modifiers instead of plugins will actually
> work really well for
> applications.
> 
> Things we need to do:
> 
> Integrate C3.
> I still do not really understand how this happens
> and how it plays
> with Moose method modifiers. Normally, I would
> ignore it, but plugins
> get tacked on to the application's ISA so that's a
> little strange. I
> re implemented most instances of ->NEXT::* as around
> modifiers, but I
> am beginning to realize that this could break some
> plugins because of
> differences between how modifiers are applied and
> how NEXT functions.
> Someone that understands this better should explain
> this to me more
> clearly if you think I am wrong here. I'm guessing
> that a good time to
> call initialize would be right after setup is
> called. Class::C3 and
> Class::C3::XS should net us a nice performance
> improvement, I think.
> I'm pretty excited about it.
> 
> Immutability
> I think, for the most part, everything can be made
> immutable
> immediately (at the end of the class file). The
> application class does
> all it's fudging with ISA at setup time, so anytime
> after setup we
> will be able to make the application immutable. One
> of the things I
> will have to eliminate though is CDI, because that
> is one of the only
> things that edits a class at runtime. Another thing
> that's still
> pending is searching for instances where *subname =
> sub{} happen at
> runtime and getting rid of those. Most of them are
> fairly simple
> things that can be changed rather easily.
> 
> Class::Inspector
> Class::Inspector is now pretty much redundant,
> because most of the
> information coming from C::Inspector can be obtained
> through the meta
> object. I'd like to get rid of whatever is left of
> Class::inspector to
> keep the code looking good.
> 
> CDI
> I think I've realized that most things that use CDI
> don't actually
> need Class Data. I know someone said so earlier but
> I am just barely
> starting to understand the codebase
> 
> NEXT
> I'm assuming we need some sort of compatibility
> layer?
> 
> New tests / updated docs
> we probably need some new tests and to update a
> couple of docs
> 
> Plugins
> I'd really like to see plugins implemented as roles.
> I recommend that
> we switch to Plugins as roles and have
> _register_plugin load each file
> and detect if it's a role or a normal plugin. Then,
> we could apply the
> plugin as whatever it is and support both ways until
> we are ready to
> kill back compat. What do you all think?

This would make a plugin I'm working on for
monitoring/restarting the application a lot easier. 
I've had to do a lot of hacking just to simulate role
stuff, so I am in favor of it.  However I think people
who have a lot of existing plugins might feel nervious
:)

-john

> 
> -- 
> Guillermo Roditi (groditi)
> 
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev at lists.scsys.co.uk
>
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
> 



      ____________________________________________________________________________________
Special deal for Yahoo! users & friends - No Cost. Get a month of Blockbuster Total Access now 
http://tc.deals.yahoo.com/tc/blockbuster/text3.com



More information about the Catalyst-dev mailing list