🚀 go-pugleaf

In article <1993Jan12.035032.23598@cs.wisc.edu> dws@ssec.wisc.edu (DaviD W. Sanderson) writes:
: >Or, alternatively, it could have all of the "standard" smarts built in,
: >but, if possible, source another script that contains local additions;
: >that way, you can keep the standard distribution and local additions
: >separate, and be able to drop in an updated standard distribution
: >without necessarily having to hack local additions in....
: 
: My perl script is designed to make it easy to add in new modules for
: local additions at 'make' time.  (And of course, you can also
: selectively omit any recognition modules you don't want.)  It does not
: use an external database because no matter how many little fobs and
: bells you allow in such a specification there will always be something
: it can't describe that you want it to.  E.g. determining whether a NeXT
: Mach executable is stripped requires traipsing through the file using
: values you pick up along the way.

But you do have an external database of sorts, if you have to do a
"make".  And Guy wasn't advocating a passive external database.  His
point still stands--if, from a standard location, you can "source" your
architecture dependent modules at runtime (and you can in Perl, using
"require") then your program can construct itself at runtime, and you
can upgrade either the architecture independent or the architecture
dependent portions without doing any "make" mumbo-jumbo, which is part
of what Perl is all about anyway.  Another way of saying it is that
Perl tries to make compile-time bindings fairly cheap in order to delay
such bindings until invocation time, and that constructing a script
with "make" may be indicative that you aren't using Perl's strengths.

Then again, maybe not.  There's more than one way to optimize your
bindings.  There are certainly valid reasons for doing it earlier--you
just haven't said any of them yet.  :-)

Larry Wall
lwall@netlabs.com