Mailing List Archive: Catalyst: Dev

Moose port progress report

Index | Next | Previous | View Threaded

groditi at gmail

Mar 30, 2008, 5:37 PM

Post #1 of 12 (779 views)
Permalink

Moose port progress report

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)

_______________________________________________
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 30, 2008, 5:51 PM

Post #2 of 12 (751 views)
Permalink

Re: Moose port progress report [In reply to]

I'd also like to ann one more thing to the TODOd

Currently, C<use Catalyst;> will alter caller's ISA and inject
Catalyst and Catalyst::Controller. I think this is not nice, and I'd
like it if we could change the recommended way to do things and the
help's script to do use (?:base|parent);

Additionally. I'd like to have use Catalyst inject ISA, but NOT
Controller. This means that people who added actions in their APP file
will see things blow because of attributes, which suck. So basically
we will have to add some attr code to Catalyst.pm that gives a helpful
error message about what exactly you are doing wrong. This means that
if you are stubborn and want to keep your actions in APP you'll have
to manually add Controller to your ISA, which isnt much work.

Anyone have a problem with that?

Also: We need more volunteers!!!!

--
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 30, 2008, 9:29 PM

Post #3 of 12 (751 views)
Permalink

Re: Re: Moose port progress report [In reply to]

* On Sun, Mar 30 2008, Guillermo Roditi wrote:
> Additionally. I'd like to have use Catalyst inject ISA, but NOT
> Controller. This means that people who added actions in their APP file
> will see things blow because of attributes, which suck. So basically
> we will have to add some attr code to Catalyst.pm that gives a helpful
> error message about what exactly you are doing wrong. This means that
> if you are stubborn and want to keep your actions in APP you'll have
> to manually add Controller to your ISA, which isnt much work.
>
> Anyone have a problem with that?
>

This will break the test suite (and the test suites of many Catalyst
modules on the CPAN). It's probably not worth it.

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

jjn1056 at yahoo

Mar 31, 2008, 7:21 AM

Post #4 of 12 (750 views)
Permalink

Re: Moose port progress report [In reply to]

--- Guillermo Roditi <groditi[at]gmail.com> wrote:

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

This would make a plugin I'm working on for
monitoring/restarting the application a lot easier.
I've had to do a lot of hacking just to simulate role
stuff, so I am in favor of it. However I think people
who have a lot of existing plugins might feel nervious
:)

-john

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

____________________________________________________________________________________
Special deal for Yahoo! users & friends - No Cost. Get a month of Blockbuster Total Access now
http://tc.deals.yahoo.com/tc/blockbuster/text3.com

_______________________________________________
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 31, 2008, 7:37 AM

Post #5 of 12 (748 views)
Permalink

Re: Moose port progress report [In reply to]

>> 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?
>
> This would make a plugin I'm working on for
> monitoring/restarting the application a lot easier.
> I've had to do a lot of hacking just to simulate role
> stuff, so I am in favor of it. However I think people
> who have a lot of existing plugins might feel nervious
> :)
>
> -john

Depends. When Catalyst is Moose-ified, what version will it be? 5.9? 6.0?

If this conversion bumps up a major version, I have no concerns with
back compat of plugins. Maybe that's just me.

Attachments:

signature.asc (0.18 KB)

autarch at urth

Mar 31, 2008, 7:39 AM

Post #6 of 12 (751 views)
Permalink

Re: Moose port progress report [In reply to]

On Mon, 31 Mar 2008, John Napiorkowski wrote:

> This would make a plugin I'm working on for monitoring/restarting the
> application a lot easier. I've had to do a lot of hacking just to
> simulate role stuff, so I am in favor of it. However I think people who
> have a lot of existing plugins might feel nervious :)

Personally, I'd like to see this work get be aggressive in its breakage of
old idioms, but have it released under a new namespace, like Catalyst6.

There's a lot of cruft in Catalyst worth excising, but at the same time, I
don't want a simple "cpan install Catalyst" to break my apps horribly ;)

-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

mike at altrion

Mar 31, 2008, 9:39 AM

Post #7 of 12 (748 views)
Permalink

Re: Moose port progress report [In reply to]

On 31 Mar 2008, at 15:39, Dave Rolsky wrote:

> On Mon, 31 Mar 2008, John Napiorkowski wrote:
>
>> This would make a plugin I'm working on for monitoring/restarting
>> the application a lot easier. I've had to do a lot of hacking just
>> to simulate role stuff, so I am in favor of it. However I think
>> people who have a lot of existing plugins might feel nervious :)
>
> Personally, I'd like to see this work get be aggressive in its
> breakage of old idioms, but have it released under a new namespace,
> like Catalyst6.
>
> There's a lot of cruft in Catalyst worth excising, but at the same
> time, I don't want a simple "cpan install Catalyst" to break my
> apps horribly ;)

Could we perhaps have a combination of a) a deprecation cycle and b)
an 'if your app breaks, set <this> config option'?
--
Mike Whitaker - mike[at]altrion.org

_______________________________________________
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 31, 2008, 12:19 PM

Post #8 of 12 (745 views)
Permalink

Re: Re: Moose port progress report [In reply to]

> This will break the test suite (and the test suites of many Catalyst
> modules on the CPAN). It's probably not worth it.

Gotcha. I still think that we should advocate the use base thing, and
mark the behavior of App ISA Controller to be deprecated. Any problem
with that?

--
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 31, 2008, 12:25 PM

Post #9 of 12 (742 views)
Permalink

Re: Moose port progress report [In reply to]

> Depends. When Catalyst is Moose-ified, what version will it be? 5.9? 6.0?
>
> If this conversion bumps up a major version, I have no concerns with
> back compat of plugins. Maybe that's just me.
>

Great question. I think there is no reason why we can't do in 5.9
seeing as how, so far, we have not broken compat. I do think however
that 6.0 is also a good target that will allow us to make some more
radical changes,

All in all, to be honest, I want to get this merged back ASAP because
I know how these projects go. If we get too ambitious we will forever
push back the merge date, the branch will start differing so much form
trunk that it'll be a huge pain to merge and the work might be lost
into the land of "Someone started a branch for that once, but it died
at 99%". I told Matt that the only way I would commit to working on
this project was the parties involved agreed to take it small steps at
a time. I am not a member of the core Cat dev team, and I don't really
have the time to be, so I want this to be done.

While on the subject, the reason I want this in 5.9 is because it
would allow us to introduce all the Moose stuff earlier and work out
all the kinks and then, for 6.0, we could deprecate some of the cruft
and introduce new ways to do things. Any problems with that? Core
devs, I am talking to all of you.

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

jshirley at gmail

Mar 31, 2008, 12:52 PM

Post #10 of 12 (746 views)
Permalink

Re: Moose port progress report [In reply to]

On Mon, Mar 31, 2008 at 12:25 PM, Guillermo Roditi <groditi[at]gmail.com> wrote:
> > Depends. When Catalyst is Moose-ified, what version will it be? 5.9? 6.0?
> >
> > If this conversion bumps up a major version, I have no concerns with
> > back compat of plugins. Maybe that's just me.
> >
>
> Great question. I think there is no reason why we can't do in 5.9
> seeing as how, so far, we have not broken compat. I do think however
> that 6.0 is also a good target that will allow us to make some more
> radical changes,
>
> All in all, to be honest, I want to get this merged back ASAP because
> I know how these projects go. If we get too ambitious we will forever
> push back the merge date, the branch will start differing so much form
> trunk that it'll be a huge pain to merge and the work might be lost
> into the land of "Someone started a branch for that once, but it died
> at 99%". I told Matt that the only way I would commit to working on
> this project was the parties involved agreed to take it small steps at
> a time. I am not a member of the core Cat dev team, and I don't really
> have the time to be, so I want this to be done.
>
> While on the subject, the reason I want this in 5.9 is because it
> would allow us to introduce all the Moose stuff earlier and work out
> all the kinks and then, for 6.0, we could deprecate some of the cruft
> and introduce new ways to do things. Any problems with that? Core
> devs, I am talking to all of you.
>

My opinion, for what it is worth since I'm not a core dev, is that 5.9
could be the moose-compat version.

Wait for 6.0 to break compat and fix the ISA Catalyst::Controller
injection type issues; then getting the app/context split at that
point is reasonable. Then there is the matter of how to properly
separate out Catalyst in CPAN so Dave's point about installing Cat
won't break everything (which I think is of considerable importance)

-J

--
J. Shirley :: jshirley[at]gmail.com :: Killing two stones with one bird...
http://www.toeat.com

_______________________________________________
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

Apr 6, 2008, 12:49 PM

Post #11 of 12 (697 views)
Permalink

Re: Moose port progress report [In reply to]

On Mon, Mar 31, 2008 at 05:39:56PM +0100, Mike Whitaker wrote:
>
> On 31 Mar 2008, at 15:39, Dave Rolsky wrote:
>
> >On Mon, 31 Mar 2008, John Napiorkowski wrote:
> >
> >>This would make a plugin I'm working on for monitoring/restarting
> >>the application a lot easier. I've had to do a lot of hacking just
> >>to simulate role stuff, so I am in favor of it. However I think
> >>people who have a lot of existing plugins might feel nervious :)
> >
> >Personally, I'd like to see this work get be aggressive in its
> >breakage of old idioms, but have it released under a new namespace,
> >like Catalyst6.
> >
> >There's a lot of cruft in Catalyst worth excising, but at the same
> >time, I don't want a simple "cpan install Catalyst" to break my
> >apps horribly ;)
>
> Could we perhaps have a combination of a) a deprecation cycle and b)
> an 'if your app breaks, set <this> config option'?

That's what we've always done before.

My intent is to get 5.80 shipped as basically fully compatible, and have
the app/ctx switch clean things up, so

use Catalyst; # will do what it always have

but

use Catalyst::AppClass; # will make us isa Catalyst::Application only

I'd also rather get away from the import style entirely, tbh; I'd prefer
a ketword-style approach ala Moose instead.

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

marcus at nordaaker

Apr 6, 2008, 2:38 PM

Post #12 of 12 (702 views)
Permalink

Re: Moose port progress report [In reply to]

On 6. april. 2008, at 21.49, Matt S Trout wrote:
>>
>> Could we perhaps have a combination of a) a deprecation cycle and b)
>> an 'if your app breaks, set <this> config option'?
>
> That's what we've always done before.
>
> My intent is to get 5.80 shipped as basically fully compatible, and
> have
> the app/ctx switch clean things up, so
>
> use Catalyst; # will do what it always have
>
> but
>
> use Catalyst::AppClass; # will make us isa Catalyst::Application only
>
> I'd also rather get away from the import style entirely, tbh; I'd
> prefer
> a ketword-style approach ala Moose instead.

I agree with the approach of releasing a fully compat moose 5.8
version. I've just released a new version of Catalyst::Devel, (1.04)
which generates MyApp.pm with "use parent qw/MyApp/" so that
controller doesn't get inserted into MyApp's isa.

changing the load style seems like a good approach for brining in the
new way of using things, while maintainin backwards compat, when we're
beyond 5.8.

I plan to do a 5.7100 release of Catalyst-Runtime this week with some
bug fixes and a few minor new features. What's the current estimated
time for the 5.8 release?

Marcus
Catalyst Release Manager.

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com