Another module I've been collaborating on is Module::Starter. Basically, I'd seen Module::Starter and Module::Setup::Template show up around the same time that I was pondering writing a n2pm (where n is "nothing") tool to replace h2xs, which I hate hate hate. Module::Setup::Template was my initial first-choice, because I didn't like the skeleton .pm files created by Starter and it wasn't, well, templated. After looking at both, though, I decided that Starter looked easier to hack on. I talked to Andy, who seemed neither excited nor put off by the changes, but was pretty open to looking at patches.
The first order of business was to make Module::Starter into a class, so that I could subclass it. Then I split up all the output-producing bits into their own subs, so they could be overridden without overriding the file-creation bits. That, plus some other stuff, got rolled into what is now Module::Starter 1.22
I committed a new Module::Starter to CVS this morning; it's all plugin-based, although the plugins are more like mixins. I'll document it tonight or this weekend sometime, and maybe we'll get a developer release out this weekend. I do like the Perlish versioning that Andy uses, with 1.21_0n versions preceding 1.22. I might start using it myself, but it would stop me from using my CVS revision number as the version. The thing is, of course, that CVS numbers are convenient for me, but not very meaningful.
Either way, Module::Starter will be available as a pluggable module Soonish. I've already got a few plugins (template storage, TT2, etc) written, and I've got a few more to write. Most of those, I think, will go in their own distributions.
Andy and I aren't working closely on every change, but it's still nice to be collaborating. I wonder if I'll ever be doing this at work.
Re:Feedback
rjbs on 2004-07-24T00:02:27
Don't I feel silly for saying Module::Setup::Template over and over? (I do.)
I'm not sure I could really say specifically what it was. I think part of it was the lines in new() that assign to $self's defaults. There are four pairs of lines that are very similar, which always makes me uncomfortable, especially if I'm just skimming. That occurs again in _get_data. I think that was probably the brunt of it.
I didn't spend a lot of time making this decision.;)
I think there are definitely ways in which MTS is cleaner than MS was, and in some ways MS is going to have to remain weird inside for a while, until MS::Simple can be rewritten a little.
Anyway, as to the repeated similarity thing, do you see what I mean? In working on some things in code left behind here, by a coworker, I saw the same thing a few times, and every time it correctly signalled refactorability. I'm not sure if that's the case in MTS, but that's part of what jarred me.Re:Feedback
jonasbn on 2004-07-24T08:37:15
Oh, great, well I know a refactoring is necessary at some point, but since I am not completely satisfied with the current state of MTS I have not thought about making a refactoring yet.
I need to get the installation proces going correctly. When this part works I would consider MTS to have met the initial goals.
After this a refactoring is will probably be a good thing.
Thanks for the great feedback...
