[Dltk-dev] Extensibility

[William Cook <william@xxxxxxxxx>]

I think that DLTK is over-engineered to require Interpeter Types
and Debug Engines. I wish you could just specify an interpreter and
give appropriate options and be done with it. I wonders if
the Eclipse launch configuration dialogs could be reused to specify
the interpreter and its attributes.

On other example I had is the order of command rendering. Currently
the interpreter arguments in the interpreter are put after the
interpreter arguments from the launch configuration. Here's what
I had to do:

Original problem:
* I have some trouble with the order of arguments. It seems to be
	1) Interpreter path
	2) interpreter arguments *from the launch configuration*
	3) Interpreter arguments *from the interpreter definition*
	4) script path
	5) script arguments
It seems to me that the #2 and #3 components are backwards, and
this causes problems with Gambit

So I hunt around and find where this functionality is defined:
in InterpreterConfig.renderCommandLine
Its a nice routine that I could override. But I cannot easily
replace the InterpeterConfig class with my own, because
AbstractScriptLaunchConfigurationDelegate says
    new InterpreterConfig
in the middle of a fairly large routine, createInterpreterConfig
(its about 60 lines long with lots of good code). If the
creation of InterpeterConfig  was through a factory, then I
would not have had to copy this code.

But I can replace AbstractScriptLaunchConfigurationDelegate with
my own, so i copy createInterpreterConfig and change the line to:
    new SchemeInterpreterConfig
Then I get an error because getScriptEnvironment is private, so
i copy it too.

I create class SchemeInterpreterConfig and implement
	renderCommandLine
But I find that there are several other overloaded versions of
it, and one of them doesn't even include item #3 in the command
line at all! I track this down, and it is called by ScriptLaunchUtil
and then i track that down and it appears never to be used. So
I assume it is dead code and move on. Anyway, it now seems to
be working.

At this point I am taking DLKT as a *library* and just implementing
my Scheme system using it. I know people have suggested that I
change DLKT itself. But I would rather not just hack on it,
because it seems very close to release and it is useful to see
how much you an do without changing it. I might later, however.

William