[Catalyst-dev] Moose + Catalyst port

[Guillermo Roditi]

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

Aha! you took my bait! No, but in all seriousness, I know that the
example i attached did something weird, but I think it's relevant to
catalyst's use of class data in ->config. config is declared as class
data in C::Component and it then uses some weird side effect about hoe
C::D::I installs subs in classes to copy the config and I think this
is exactly the behavior that was shown on my test.

When a subclass of a class with a MooseX::ClassAttribute changes the
value of that data, it changes in the superclass too. When C::D::I
does it, it doesn't the change is localized (for lack of a better
word) to the subclass.

I am not saying one way is right and the other is wrong. I personally
happen to think that ClassAttribute DTRTs, but that's just not the way
Catalyst currently works. To use MX::CA we would have to specify
class_has on every subclass.

>
>  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 { ... };

I agree too, the sugar comes later though. My original vision was to
use custom method metaclasses for different types of actions, which
would in turn have attributes that represent the options for that type
of action.

Initially, I think that we could keep attributes and store their value
in the method metaclass as well as maybe add a couple of keywords that
allow you to add methods too. that way both the old and new approaches
would work.

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

After 6 hours of hacking on this I am still so fucking lost. i guess i
just do not grok NEXT or something. I just can't explain to myself why
a class with no superclasses would ever call NEXT.

-- 
Guillermo Roditi (groditi)