[plt-scheme] Easy module switching?
On Jun 28, 2007, at 11:38 AM, Henk Boom wrote:
> On 27/06/07, John Clements <clements at brinckerhoff.org> wrote:
>> Units are designed to handle this kind of problem, though in fact
>> units give you run-time binding, which might be more flexibility than
>> you really want.
>
> I know about units (at least the plt ones), though I admit my
> understanding of them is rather primitive. The idea I get is that they
> are a tool comparable to, although more flexible and powerful than,
> C++ templates. I don't understand how they would help.
>
The comparison is wrong. The problem with module is that it doesn't
separate specification and implementation. Your goal is to swap one
module for another one that provides the same name but has "enriched"
services. This is exactly (one of) the problem(s) that units solve.
Units implement interfaces. Primitive units are linked together,
so that "clients" are connected to "servers" of the promised
functionality. The linking language is powerful and allows, in
particular, a "run time" (you could call it link time) decision
of which "server" to use. Thus, you could write
#! /bin/sh
#|
exec mzscheme -qu "$0" ${1+"$@"}
|#
(module myscript mzscheme
(define argv (command-line-arguments))
(compound/unit ...
[server : Server^ (if (something? argv) server at --fast server at -debug]
[client : ... server]
...))
and then run
$ ./my-script --debug
to switch out the modules. No change to source code required.
> Basically I want to be able to swap between different versions of a
> module from a central location, preferably without having to actually
> rename the module or change the source file(s). The command line would
> be a convenient place to be able to set it from. For example, one
> solution would be to have all of my files require a new "router"
> module which would require one of the alternatives depending on which
> I wanted to use. However, to switch between them I would actually have
> to change the source of this router module. I want to know if there is
> a more convenient alternative.
I do have sympathy for your desire. I have run into the exact same
problem myself twice over the past year:
1. with the object tracer, which needs to replace class.ss with class-
debug.ss,
2. with a game project, where I forced myself to use modules for a
primitive OO style.
I did implement the same interface more than once -- and ended up
editing source code.
I did consider writing the main script so that it would switch (copy)
the module
files into the proper location before running the program. But this
solution
looked so inelegant that I just couldn't bring myself to do it.
-- Matthias