On Mon, May 18, 2009 at 6:27 PM, Tomas Doran <[email protected]> wrote:
> J. Shirley wrote: > >> While an obvious blunder to make while coding, I wasn't alerted to >> anything and the application started with no warnings and no indication that >> something was wrong. The only thing is that my 'rpx' method no longer was >> dispatchable. >> >> Oops. >> > > Hmm, I think that this is actually by design: > > > http://search.cpan.org/~drolsky/Moose-0.79/lib/Moose/Manual/FAQ.pod#I_created_an_attribute,_where_are_my_accessors<http://search.cpan.org/%7Edrolsky/Moose-0.79/lib/Moose/Manual/FAQ.pod#I_created_an_attribute,_where_are_my_accessors> > ? > > I'm sure there is a better explanation somewhere, but I can't find it right > now. > I was/am actually populating much more than just 'is' -- I was mostly talking about the failure of a warning. I would like to see something like the subroutine redefine warning... as you mentioned :) > > > So, I'm pretty far out of my depth for 5.8 but I'd be happy to commit a >> failing test case -- is the proper test case a situation like this, and >> failing if the method doesn't define a dispatchable path or something else? >> I can imagine this is something that could commonly come up and bite people >> who aren't careful (or working with thick controllers) >> > > I don't think there's any great way to get around this which I can think of > right now. > > The best solution I could come up with is to make Catalyst::Controller > apply a default attribute trait which warned when (Moose) attributes were > added which overrode methods with (perl) attributes. > > If you'd like to commit TODO tests (there is already a Moose specific > controller in the test suite) which test for an appropriate warning being > emitted during app startup, then I'll have a crack at seeing if I can do > something sane enough to be maintainable.. > I'll see what I can do about this and try not to forget... I'm traveling a far distance this week, so if I drop the ball on this you can kick me next week if you remember. > > > package MyApp::Controller::Auth; > > > > use parent 'Catalyst::Controller'; > > > > use Moose; > > > > has 'rpx' => ( is => 'rw' ); > > > > sub rpx : Chained('/') Args(0) { } > > > > 1; > > Note this pattern works, but is mildly disrecommended going forwards. There > are tests in the test suite that it works in basic cases, but it's not what > people are using - so I wouldn't be confident it will stay working for > non-trivial cases (I have already fixed bugs with doing it this way round). > > My Moose native controllers look like this: > > package MyApp::Controller::Auth; > use Moose; > use namespace::autoclean; > > BEGIN { extends 'Catalyst::Controller'; } > > # Attributes and actions > > __PACKAGE__->meta->make_immutable; # Note this returns true, so is good for > the last line > > I did scribble _some_ stuff in Catalyst::Manual::ExtendingCatalyst about > this, but if you'd like to add anything (or at least tell us what it's > missing currently), that'd be awesome? > > I assume you mean Upgrade (since Catalyst::Manual is still at 5.7x) - http://search.cpan.org/~flora/Catalyst-Runtime-5.80003/lib/Catalyst/Upgrading.pod#Components_which_inherit_from_Moose::Object_before_Catalyst::Component If so... uhm, why :) I'm curious how the BEGIN block makes the attributes work (and bypasses Moose::Object), if you don't mind being Professor Tom for a bit, that is. Thanks, -J
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
