[Catalyst-dev] Moose + Catalyst port

[Zbigniew Lukasiak]

On Sat, Mar 15, 2008 at 2:33 AM, Guillermo Roditi <groditi at gmail.com> wrote:
> OK,
>
>  In case you were not aware, konobi is working on a Moosified Catalyst
>  branch. I just joined the effort today, but since I am not very
>  familiar with the cat internals I ran into some trouble. Most of my
>  issues had to do with the way Catalyst uses class data and MI.
>
>  Questions:
>  Anyone familiar with both Class::Data::Inheritable and MooseX::ClassAttribute ?
>  Catalyst uses class data in a couple of key spots and I'm not familiar
>  with either of the above modules other than what I've been learning
>  today, but after writing a short test, which is attached below, i
>  noticed they are not compatible.  Suggestions?
>
>  Here are some proposals, feel free to tell me how wrong I am, but
>  please tell me why:
>
>  * Implement Catalyst::AttrContainer as role.
>  Problem here stems from class data. How do we create class data in a role?
>  It was my original intention to use MooseX::ClassAttribute, but that
>  won't work. I'd like to see some suggestions here, if anyone has any.
>
>  * Catalyst::Controller
>  is the only subclass of AttrContainer. should we just move the code in
>  here? and avoid the mess above?
>
>  * Catalyst::Component
>  More Class::Data::Inheritable woes. See &config to see what I mean. I
>  don't understand the desired end result, so I don't know how to
>  recreate the behavior and test for it
>  COMPONENT calls $self->NEXT::COMPONENT. why? We have no superclasses.
>  I figure this is a MI thing. Are we sticking with NEXT for the Moose
>  port? I was thinking of moving to just using method modifiers. I have
>  no clue what to replace this call with. I could use some help here.
>  COMPONENT, in the case of not being able to build a new instance via
>  new just blesses the config + args. Uhm. do we need to keep compat for
>  this? The Moose port will always return an object on new because
>  Moose::Object will do that for us.
>
>  * Multiple Inheritance
>  It seems to me that by using roles we could totally eliminate this
>  from the codebase
>
>  * NEXT::* / SUPER::* / next::method / super()
>  Like I mentioned above.. what do we want? are we just using Moose
>  method modifiers or do we want to use NEXT or next or whatever
>

In general I would say - do something sane and then build a
compatibility layer on top of it just like mst did with CDBI.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/