« Opensource / Free software, Volunteerism and Support | Main | Status Update on Catalyst-ActionRole-BuildDBICResult »

05/31/2010

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

phaylon

This looks like an extremely useful module. Personally, I think I wrote something like this but more incomplete about 3 times. Some of my pet projects collect different kinds of data from large object trees, so this would be nice.The idea of providing configurable patterns with good defaults via parameterized roles is very intriguing in general. I have a very simple factory pattern role that I use to include external class dependencies, including lazy loading, overriding the used classes during object construction, default constructor arguments, and easy construction via -_new_$dep(...).

John Napiorkowski

[this is good] phaylon,

After seeing some of the bits from DBIC::DeploymentHandler
(http://search.cpan.org/perldoc?DBIx::Class::DeploymentHandler) I
realized I was dreadfully misunderstanding parameterized roles, so I
used this new project as an excuse to play a bit :)

However I think in this case I had two options I could think of, either put everything in
the handler role and tell people to override with straight up Moose
inheritance, or use the parameterized role. If I had done that I'd have
replaced:



package Loader::Filesystem;





use Moose;


with 'MyApp::Loader';


with 'Patterns::ChainOfResponsibility::Role::Handler', { dispatcher = '::Provider' };

with something like:



package Loader::Filesystem;





use Moose;


with 'MyApp::Loader';

with 'Patterns::ChainOfResponsibility::Role::Handler'; has '+dispatcher_class' = (default = '::Provider');Which is fine I guess but since these bits belonged to the role I felt the parameterized role option was better.

John Napiorkowski

Also, I imagine this as more of a toolkit with several options and approaches. I you have something interesting for the factory pattern I'd love to see that thrown out there. The factory is a tricky one with perl I think since they are very useful in Java but often feel like overkill for Perl. I great example would be awesome.thanks!

phaylon

I've put a simple example on gist at http://gist.github.com/420295 . I agree that the parameterized version is nicer. Having to access the attribute directly feels like violating encapsulation to me, even though it probably isn't.

Dave Rolsky

Last time I looked through the GoF book, it seemed like a large number of design patterns were irrelevant in Perl. Perl can dispatch properly when the class name and/or method name is in a string created at runtime. This obsoletes quite a number of patterns, many of which seem focused on working around the fact that in Java, dispatch is determined at compile timeI actually did a presentation about this a while ago.

John Napiorkowski

Thanks for the linkage, I'll review it certainly!The whole design patterns thing is a bit of a catch22 for me. On the one hand as you say quite a few are not design patterns in a platonic ideal sense, but more like strategies to deal with Java and similar languages. On the other hand I think it would be a good idea for us on the Perl side to counter/provide alternatives if only as part of advocacy.I think my first goal here is to write up reasonable examples of all the patterns I think are actually very useful for dynamic languages and then go on the the ones that may not be or for which different but valid approaches exist.

The comments to this entry are closed.