[Catalyst-dev] Moose + Catalyst port

[Dave Rolsky]

On Fri, 14 Mar 2008, Guillermo Roditi wrote:

> Anyone familiar with both Class::Data::Inheritable and MooseX::ClassAttribute ?

Yes.

> 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?

CDA does a sort of magic weirdness with inheritance and setting the 
accessor. I'm not sure that's relevant to Catalyst's use of class data.

In some cases where Catalyst uses class data, I'm not sure it's really 
needed anyway.

> * 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.

I think if you're going to bother Moose-ifying Catalyst, you might as well 
look into replacing the attribute-based declarations with something 
Moose-like. I know mst has thoughts on this.

Off the top of my head, I'd imagine something like this:

  dispatch local => sub { ... };

  dispatch chained '_chain_start' => args 1 => sub { ... };

> 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.

One thing you'll need to do is look for uses of this sort of stuff in 
plugins, which is what COMPONENT is used for, AFAICT. Same goes for 
ACCEPT_CONTEXT.

Again, I could imagine a more declarative form based on Moose sugar for 
this sort of thing.

> * Multiple Inheritance
> It seems to me that by using roles we could totally eliminate this
> from the codebase

That'd be great.


I think the biggest thing to think about is plugins, since that's a major 
piece of how Catalyst works. It'd be nice if plugins could be defined in a 
way that didn't involve jamming a bazillion roles into the Catalyst 
namespace ;)


-dave

/*==========================
VegGuide.Org
Your guide to all that's veg
==========================*/