[Matchstick-dev] coge gen, or modular

[Michael P. <mp...@pl...>]

From Sam Tregar's Matchstick goals:

>    2.  Is it better to create a code-generator, like h2xs, or a modular
>        system utilized via extension? A code-generator may be easier to
>        develop but it wouldn't be possible to upgrade the results when new
>        Matchstick are born.

I've been thinking about this back and forth and here are my intial pros/cons of
each approach:

Code-Generator
==============
PROS
  1) Familiar to Perl developers. Not only h2xs but Module::Starter.
  2) Easier for individual projects to customize to their needs. Everything is
  editable/extendable. You don't have to worry about overriding
  private methods or hoping that what you want to extend is even in subclassable
  methods. The code is all yours to change.
  3) Easier to develop

CONS
  1) Code generation kinda leaves a bad taste in some mouths. But there are a
couple of reasons I'm not convinced that this is horrible. Perl programmers are
used to some code-gen (Module::Build and ExtUtil::MakeMaker). Also, most of this
code will probably be customized, so it's not some big mystery black box that
they shouldn't touch.
  2) Upgrading your version of Matchstick. This seems to be the biggest con, but
I think there are ways of approaching this. I'll probably make this a separate
email.

Modular
=======
PROS
  1) Nice and clean.
  2) Easier to upgrade. Just update the modules and blamo! But since we are
encouraging a lot of subclassing, changes cannot always be orthogonal and
upgrading a project's version of Matchstick will probably not be trivial even in
with this approach.

I know matchstick is new, but the concepts have been around for a while. Do we
anticipate rapid changes moving forward? This answer may affect how important
the framework-upgrade facility is.

CONS
  1) Deciding how much will go into modules. Should all logic that is in scripts
be put into modules so that scripts are just thin wrappers around modules? How
much needs to be subclassable?
  2) More work anticipating user's needs/wants. Also more work trying to please
more different styles of doing the same thing (logging?)
  3) Slightly harder to customize since you have to sublcass the module you're
changing and also any other modules that use it.

Additions to the above? If you haven't guessed, I'm leaning towards the
Module::Starter-like approach (code and layout generation).

-- 
Michael Peters
Developer
Plus Three, LP