# from David E. Wheeler # on Wednesday 18 June 2008 07:54: >On Jun 18, 2008, at 01:57, Eric Wilhelm wrote: >>> so I guess that subclassing isn't >>> necessarily the best way to go. >> >> Do you have enough tuits to dust-off the "plugin architecture" >> thread? > >Link?
http://www.nntp.perl.org/group/perl.module.build/2008/03/msg1298.html There are more if you point your favorite search engine at nntp.perl.org/group/perl.module.build and ask about plugins. >How hard can it be? (He asks, ignoring the dragons.) The dragons I've seen are the difficulty of testing and lack of coverage - particularly with regard to multiple environments and configurations. >> And then there's the thing where some features are optional and the >> dependencies aren't necessary for the install (e.g. developer >> targets.) > >Huh? Plugins can be distributed separately, with their own >dependencies, I'm sure. If a plugin is not needed for the 'build', 'test', or 'install' targets on a target (user) machine, there should be a way to make it optional. We also have to make sure that whatever gets printed to the compatibility Makefile.PL accounts for that or uses a plain M::B - or just refuse to write a Makefile.PL if it's not easily solvable. --Eric -- perl -e 'srand; print join(" ",sort({rand() < 0.5} qw(sometimes it is important to be consistent)));' --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
