[Catalyst-dev] Moose port progress report

[Guillermo Roditi]

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?

-- 
Guillermo Roditi (groditi)