RE: Modularizing cons

[Gary Oberbrunner]

Greg wrote:
 > I have the same reservations about the level of detail necessary when
 > you want to do something special, like reorder the command line args, or
 > add functionality to a class...

What worries me (a little) is that what I want to do is build plug-in
components on all the platforms.  Plug-ins are like shared libraries, but
usually built with a custom set of flags.  So I want to make sure I don't
have to override every single compiler tool's command-line building method!
Maybe there's a compromise, where a compiler tool could use a simple string
as the command line template, and substitute necessary stuff into it.  Users
could override that quite easily.

 >  The up side is that the changes are usually very self-contained

I agree -- looking at your code this seems very true -- much simpler than
cons today.

 > ... it's very hard to make a tool that is just as
 > simple when someone wants to do the unusual.

Amen to that.  The ideal design is one that lets you learn the innards
incrementally, the more intense your customization gets.

 > Also, if I want to generate some config value (maybe a moving target,
 > like a license key, or a version number) on the fly instead of having it
 > have a static value, it's easier to do that inside of a member function
 > than it is to create a perlref as an argument and make sure everything
 > handles that correctly...

Agreed, I think this can be a big win.  For instance you could replace the
current %[ %] code by replacing, say, the compiler's command-line generator
with something that calls the regular version and then does your customized
tweaking.  (Not saying we actually should take that out -- it's cool.)

-- Gary Oberbrunner