Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Dev

Moose + Catalyst port

 

 

Catalyst dev RSS feed   Index | Next | Previous | View Threaded


groditi at gmail

Mar 14, 2008, 6:33 PM

Post #1 of 22 (875 views)
Permalink
Moose + Catalyst port

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

--
Guillermo Roditi (groditi)

####BEGIN ClassAttribute VS C::D::I tests
{
package CDAFoo;
use base qw(Class::Data::Inheritable);
CDAFoo->mk_classdata('beep');
CDAFoo->mk_classdata('bop');

package CDABar;
use base 'CDAFoo';
CDABar->mk_classdata('beep');
}

{
package MCAFoo;
use Moose;
use MooseX::ClassAttribute;
class_has 'beep' => (is => 'rw');
class_has 'bop' => (is => 'rw');

package MCABar;
use Moose;
use MooseX::ClassAttribute;
extends 'MCAFoo';
class_has 'beep' => (is => 'rw');
}

package main;

use strict;
use warnings;
use Test::More tests => 6;

CDAFoo->beep('FOO BEEP');
CDAFoo->bop('FOO BOP');
MCAFoo->beep('FOO BEEP');
MCAFoo->bop('FOO BOP');

is(CDAFoo->beep, MCAFoo->beep, 'FOO BEEP');
is(CDAFoo->bop, MCAFoo->bop, 'FOO BOP');

CDABar->beep('BAR BEEP');
CDABar->bop('BAR BOP');
MCABar->beep('BAR BEEP');
MCABar->bop('BAR BOP');

is(CDABar->beep, MCABar->beep, 'FOO BEEP');
is(CDABar->bop, MCABar->bop, 'BAR BOP');

is(CDAFoo->beep, MCAFoo->beep, 'FOO BEEP');
is(CDAFoo->bop, MCAFoo->bop, 'BAR BOP');

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


groditi at gmail

Mar 14, 2008, 6:36 PM

Post #2 of 22 (849 views)
Permalink
Re: Moose + Catalyst port [In reply to]

In addition, what are the chances of getting some SoC help for this
project. It seems like it's attainable.

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


autarch at urth

Mar 14, 2008, 9:24 PM

Post #3 of 22 (856 views)
Permalink
Re: Moose + Catalyst port [In reply to]

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
==========================*/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


groditi at gmail

Mar 14, 2008, 10:54 PM

Post #4 of 22 (850 views)
Permalink
Re: Moose + Catalyst port [In reply to]

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

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


zzbbyy at gmail

Mar 15, 2008, 12:23 AM

Post #5 of 22 (853 views)
Permalink
Re: Moose + Catalyst port [In reply to]

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/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


mike at altrion

Mar 15, 2008, 1:13 AM

Post #6 of 22 (847 views)
Permalink
Re: Re: Moose + Catalyst port [In reply to]

On 15 Mar 2008, at 01:36, Guillermo Roditi wrote:

> In addition, what are the chances of getting some SoC help for this
> project. It seems like it's attainable.

It's down to what we get in the way of project apps. Having said
that, if you want to create yourself an account on the TPF wiki and
add some more detail to that project, that won't hurt :)
--
Mike Whitaker | Perl developer, writer, guitarist, photographer
mike[at]altrion.org | Board member, http://www.englightenedperl.org/
Y!: tuxservers | Blog: http://perlent.blogspot.com/
IRC: Penfold | CatSwag: http://www.cafepress.com/catalystdev




_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


mike at altrion

Mar 15, 2008, 1:14 AM

Post #7 of 22 (851 views)
Permalink
Re: Moose + Catalyst port [In reply to]

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

Maybe in the long term :)

Short term, the Holy Grail is backwards compatibility :)
--
Mike Whitaker | Perl developer, writer, guitarist, photographer
mike[at]altrion.org | Board member, http://www.englightenedperl.org/
Y!: tuxservers | Blog: http://perlent.blogspot.com/
IRC: Penfold | CatSwag: http://www.cafepress.com/catalystdev




_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


diment at gmail

Mar 15, 2008, 1:24 AM

Post #8 of 22 (849 views)
Permalink
Re: Re: Moose + Catalyst port [In reply to]

On 15 Mar 2008, at 19:13, Mike Whitaker wrote:

>
> On 15 Mar 2008, at 01:36, Guillermo Roditi wrote:
>
>> In addition, what are the chances of getting some SoC help for this
>> project. It seems like it's attainable.
>
> It's down to what we get in the way of project apps. Having said
> that, if you want to create yourself an account on the TPF wiki and
> add some more detail to that project, that won't hurt :)
>

That's at http://www.perlfoundation.org/perl5/index.cgi?
gsoc2008_projects by the way - openid is one of the supported
authentication methods too, so no yucky passwords to remember.

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


autarch at urth

Mar 15, 2008, 8:11 AM

Post #9 of 22 (850 views)
Permalink
Re: Moose + Catalyst port [In reply to]

On Sat, 15 Mar 2008, Guillermo Roditi wrote:

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

I think it does this because it may have _subclasses_.


-dave

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

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


claco at chrislaco

Mar 15, 2008, 8:43 AM

Post #10 of 22 (846 views)
Permalink
Re: Moose + Catalyst port [In reply to]

Dave Rolsky wrote:
> On Sat, 15 Mar 2008, Guillermo Roditi wrote:
>
>>> > 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.
>
> I think it does this because it may have _subclasses_.

Or, think of it another way. Instead of subclasses...aka stacking
classes on top of each other... think composition...stacking classes
beside each other in another class. Like plugins that don't sublasses
anything, but get stuffed into something else. And NEXT just allows them
to pass traffic along to the next guy, without knowing who the next guy
really is.
Attachments: signature.asc (0.18 KB)


groditi at gmail

Mar 15, 2008, 10:31 AM

Post #11 of 22 (844 views)
Permalink
Re: Moose + Catalyst port [In reply to]

> > I think it does this because it may have _subclasses_.
>
> Or, think of it another way. Instead of subclasses...aka stacking
> classes on top of each other... think composition...stacking classes
> beside each other in another class. Like plugins that don't sublasses
> anything, but get stuffed into something else. And NEXT just allows them
> to pass traffic along to the next guy, without knowing who the next guy
> really is.

Ok, so I guess this question breaks down further.
Should I be using method modifiers or NEXT or next? I need a core dev
to really answer that. I thought we would be moving to method
modifiers, but that won't work just like that, mainly because I can't
use a method modifier unless another method already exists either in
the same file, a previously consumed role, or up the ISA hierarchy,
which means that there would be nothing on top for
&COMPONENT::COMPONENT to extend, hence the call would be a no-op.

Do I make sense?

I understand why it's being used, but won't it be unnecessary to have
this if Catalyst, C::M, C::V and C::C lose the MI?

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


jon at jrock

Mar 15, 2008, 1:25 PM

Post #12 of 22 (846 views)
Permalink
Re: Moose + Catalyst port [In reply to]

* On Sat, Mar 15 2008, Guillermo Roditi wrote:
>> > I think it does this because it may have _subclasses_.
>>
>> Or, think of it another way. Instead of subclasses...aka stacking
>> classes on top of each other... think composition...stacking classes
>> beside each other in another class. Like plugins that don't sublasses
>> anything, but get stuffed into something else. And NEXT just allows them
>> to pass traffic along to the next guy, without knowing who the next guy
>> really is.
>
> Ok, so I guess this question breaks down further.
> Should I be using method modifiers or NEXT or next? I need a core dev
> to really answer that. I thought we would be moving to method
> modifiers, but that won't work just like that, mainly because I can't
> use a method modifier unless another method already exists either in
> the same file, a previously consumed role, or up the ISA hierarchy,
> which means that there would be nothing on top for
> &COMPONENT::COMPONENT to extend, hence the call would be a no-op.
>
> Do I make sense?
>
> I understand why it's being used, but won't it be unnecessary to have
> this if Catalyst, C::M, C::V and C::C lose the MI?

Method modifiers. NEXT is one of the worst pieces of software ever
written. It needs to die.

The only reason we use MI in Catalyst is for extensibility reasons.
Roles will replace MI for this.

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


jon at jrock

Mar 15, 2008, 1:40 PM

Post #13 of 22 (848 views)
Permalink
Re: Moose + Catalyst port [In reply to]

* On Fri, Mar 14 2008, Dave Rolsky wrote:
> 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.

COMPONENT is for instantiating a Component at Catalyst startup time.
ACCEPT_CONTEXT is for instantiating a Component at request time. This
model doesn't need to change.

> 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 ;)

Most of the things that are plugins shouldn't be. Sessions and
Authentication will both be models. That leaves plugins for things
like:

package MyApp;
use Catalyst qw(DebugRequest); # this is now one of those clever
# Moose->import_to things


package Catalyst::Plugin::DebugRequest;

before 'prepare_action' => sub {
my ($c) = @_;
$c->log->debug( 'About to handle '. $c->req->uri );
}

This doesn't really clutter the namespace because it's just modifying
things. I suppose plugins can add methods, but let's not document that
and see what happens.

It should be possible to apply Plugins to the other classes:

* config (let's make this a class; a plugin can then load config
files, etc.)

* request

* response

* logger (maybe standardize on MX::LogDispatch)

* application (that's the above thing)

* context

* stash (?) # the idea here is to impose some structure on $c->stash
# on a per-request basis

This is easy enough to implement:

package Catalyst;
has logger => (
is => 'ro',
isa => 'Catalyst::Log',
default => sub {
Moose::Meta::Class->create_anon_instance(
superclasses => ['Catalyst::Log'],
roles => [$self->_logger_roles],
};
);

As for sessions, let's use Data::Session for Catalyst::Model::Session.
Code is currently at http://git.jrock.us/?p=Data-Session.git;a=summary

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


groditi at gmail

Mar 15, 2008, 2:04 PM

Post #14 of 22 (848 views)
Permalink
Re: Moose + Catalyst port [In reply to]

> COMPONENT is for instantiating a Component at Catalyst startup time.
> ACCEPT_CONTEXT is for instantiating a Component at request time. This
> model doesn't need to change.

And it won't. But my main issue was that I couldn't strip NEXT out of Component
until I read your last message. My new sub looks like this :

sub COMPONENT {
my ( $self, $c ) = @_;
# Temporary fix, some components does not pass context to constructor
my $arguments = ( ref( $_[-1] ) eq 'HASH' ) ? $_[-1] : {};
return $self->new( $c, $arguments );
}

Which should work because since this will be the base, the old next
behavior can just be achieved with "around COMPONENT => sub {...};"


> > 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 ;)
>
> Most of the things that are plugins shouldn't be. Sessions and
> Authentication will both be models. That leaves plugins for things
> like:

Yeahhh. we'll see. For the time being I'd like to keep some sort of
compat until we have a critical mass of converted plugins. mst will
help, as evidenced by the following:

14:53 <@mst> I'll do that part if others won't
14:53 <@mst> I -enjoy- compat hacking

Well volunteered!

> package MyApp;
> use Catalyst qw(DebugRequest); # this is now one of those clever
> # Moose->import_to things

Class level or instance level? quick, pick one! I vote class-level.

> It should be possible to apply Plugins to the other classes:

Then those classes should be pluggable themselves?

> * config (let's make this a class; a plugin can then load config
> files, etc.)

How exactly do you propose this one works? I just don't see what you
mean. I like it just fine as an accessor to a hashref, I think it
works nicely.

> * request
> * response
> * logger (maybe standardize on MX::LogDispatch)
> * application (that's the above thing)
> * context

Notice the App / CTX split is not done yet and is outside the scope of
this project. if someone figures out the details with that I'd be glad
to merge the patches to the moose port, but I am not putting my hands
in that mess just yet.

> * stash (?) # the idea here is to impose some structure on $c->stash
> # on a per-request basis

Again, I am not disagreeing, but I think those things are outside the
scope of this port and can be developed separately and then merged in.
One bite at a time.

> This is easy enough to implement:
> package Catalyst;
> has logger => (
> is => 'ro',
> isa => 'Catalyst::Log',
> default => sub {
> Moose::Meta::Class->create_anon_instance(
> superclasses => ['Catalyst::Log'],
> roles => [$self->_logger_roles],
> };
> );

There's other ways to do it as well, but yeah, it can work like that.
My idea to make the other classes pluggable would have worked
something like:

around _build_logger => sub {
my $logger = shift->(@_);
$logger->load_plugin("My::Role::Plugin");
};

But then again, it's too early for this kind of talk. APIs should be
designed more carefully and with more input.


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


autarch at urth

Mar 15, 2008, 2:51 PM

Post #15 of 22 (850 views)
Permalink
Re: Moose + Catalyst port [In reply to]

On Sat, 15 Mar 2008, Jonathan Rockway wrote:

> This doesn't really clutter the namespace because it's just modifying
> things. I suppose plugins can add methods, but let's not document that
> and see what happens.

What I'd really like is a way to add _one_ method via a plugin, while
keeping most of the logic outside the plugged-into class.

For example, I like to add a "$c->user()" (or it could be
"$c->request()->user()") method. I don't need to add the
"_determine_user_from_cookie()" method I'm using under the hood, though.


-dave

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

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


groditi at gmail

Mar 15, 2008, 3:12 PM

Post #16 of 22 (848 views)
Permalink
Re: Moose + Catalyst port [In reply to]

> What I'd really like is a way to add _one_ method via a plugin, while
> keeping most of the logic outside the plugged-into class.
>
> For example, I like to add a "$c->user()" (or it could be
> "$c->request()->user()") method. I don't need to add the
> "_determine_user_from_cookie()" method I'm using under the hood, though.

Hmmmm, I like this, but I suspect the way to do it would be to:

add attribute: user that isa UserClass|Undef with a default sub which
takes care of building the value (or not). The default CodeRef could
then call class methods on the user class with the appropriate
Catalyst data to to do it's thing and return a built object or undef
if there is no user.

Or we could extend the accessor to, in the case there is no user
object yet, make it see if the appropriate data is there to build the
user object and if it's not just return.


Anyways... details like this are way too specific for this stage of the game.


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


groditi at gmail

Mar 15, 2008, 3:55 PM

Post #17 of 22 (845 views)
Permalink
Re: Moose + Catalyst port [In reply to]

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

This is actually where I am not permanently stuck. I don't think there
is a way for us to escape C::D::I, because that weird clone behavior
it is doing is relied upon in a lot of places. So, What to do? Try to
keep C::D::I or what?

Basically, any package that inherits a class data accessor is
affected. This sucks a whole lot.


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


jon at jrock

Mar 15, 2008, 7:39 PM

Post #18 of 22 (844 views)
Permalink
Re: Moose + Catalyst port [In reply to]

* On Sat, Mar 15 2008, Dave Rolsky wrote:
> On Sat, 15 Mar 2008, Jonathan Rockway wrote:
>
>> This doesn't really clutter the namespace because it's just modifying
>> things. I suppose plugins can add methods, but let's not document that
>> and see what happens.
>
> What I'd really like is a way to add _one_ method via a plugin, while
> keeping most of the logic outside the plugged-into class.
>
> For example, I like to add a "$c->user()" (or it could be
> "$c->request()->user()") method. I don't need to add the
> "_determine_user_from_cookie()" method I'm using under the hood,
> though.

I've gotten pretty religious about not cluttering up my namespace with
"internal" methods that I never expect to override (or modify) in
subclasses. To achieve this, there are a few things I do.

First, lexically-scoped subs:

my $internal_utility = sub { ... };

sub external_interface {
my ($self) = @_;
$internal_utility->($self, ...);
}

The disadvantage here is that subclasses can't do anything with these,
and testing the internal methods by calling them directly is not
possible. That can be worked around, perhaps with PadWalker.

Another helpful policy is to never name things that you're only going to
use once. Instead of:

has 'foo' => (
is => whatever,
isa => foobar,
default => \&_make_foo,
);

sub _make_foo { }

I prefer:

has 'foo' => (
is => whatever,
isa => foobar,
default => sub { ... },
);

I can't think of a good mechanism for only applying public methods. The
best thing to do is relax and not think about it too much. Some
namespace clutter is inevitable, and the nice part of roles is that
Moose will refuse to apply roles that contain conflicting methods.

As an example of "relaxing", when I was learning CLOS I got really
stressed out about (set-slot). That's going to totally break my class
if someone calls (set-slot 'foo bar) instead of going through my
accessor. What a terrible object system!111!! *fume, fume*

Then I realized that you just don't call set-slot. It's there, but you
don't have to use it. Private methods are the same way. Don't touch
them and they won't bite you :)

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


pagaltzis at gmx

Mar 16, 2008, 6:56 AM

Post #19 of 22 (846 views)
Permalink
Re: Moose + Catalyst port [In reply to]

* Jonathan Rockway <jon[at]jrock.us> [2008-03-16 03:45]:
> First, lexically-scoped subs:
>
> my $internal_utility = sub { ... };
>
> sub external_interface {
> my ($self) = @_;
> $internal_utility->($self, ...);
> }

Note that you can write that like a regular method call:

$self->$internal_utility(...);

You basically just switch convention from the common “internal
methods start with an underscore” to “internal methods start with
a dollar sign.”

> The disadvantage here is that subclasses can't do anything with
> these, and testing the internal methods by calling them
> directly is not possible. That can be worked around, perhaps
> with PadWalker.

Or less magically, you can write a meta-object style class method
that returns a hash of private methods. The point is not to make
it impossible to reach them, just to make sure they don’t spill
into any namespace.

> Then I realized that you just don't call set-slot. It's there,
> but you don't have to use it.

Yes, the Perl living room and shotgun argument.

> Private methods are the same way. Don't touch them and they
> won't bite you :)

Sure. We’re not nervous about people who do naughty things
getting what they deserve. Rather, the real problem is the other
way around: the author of a subclass must pay close attention not
to define faux-private methods with names that its superclasses
already use. Worse yet, the maintainer(s) of those superclasses
cannot define new private methods because s/he cannot be sure
that a subclass hasn’t taken that name already.

We all know that lexical scoping is good for variables, and not
because of deliberate interlopers so much as for protection from
accidental collisions. That principle doesn’t lose validity when
the things being named are methods rather than variables.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


dbix-class at trout

Mar 16, 2008, 10:31 AM

Post #20 of 22 (847 views)
Permalink
Re: Moose + Catalyst port [In reply to]

On Sat, Mar 15, 2008 at 06:55:25PM -0400, Guillermo Roditi wrote:
> > 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.
>
> This is actually where I am not permanently stuck. I don't think there
> is a way for us to escape C::D::I, because that weird clone behavior
> it is doing is relied upon in a lot of places. So, What to do? Try to
> keep C::D::I or what?

No.

Throw out _config, rewrite ->config to DTRT.

End of problem.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


dbix-class at trout

Mar 16, 2008, 10:33 AM

Post #21 of 22 (842 views)
Permalink
Re: Moose + Catalyst port [In reply to]

On Fri, Mar 14, 2008 at 11:24:00PM -0500, Dave Rolsky wrote:
> 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.

All of which start with "Once we've got it ported and attributes working".

Punt. Discuss later. Can't replace things compat requires.

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

COMPONENT is a constructor. It has nothing to do with plugins.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


dbix-class at trout

Mar 16, 2008, 10:34 AM

Post #22 of 22 (851 views)
Permalink
Re: Moose + Catalyst port [In reply to]

On Sat, Mar 15, 2008 at 01:54:27AM -0400, Guillermo Roditi wrote:
> > > 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.

It's so you can do

use base qw(Catalyst::Component SomethingElse::WithA::ComponentMethod);

and both classes' COMPONENT method get called.

remember NEXT::COMPONENT is equivalent to maybe::next::method from C3,
not next::method.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Catalyst dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.