Re: [Hecl-devel] Subclassing Interp or Auxiliary Data for Interpreter

[David W. <dav...@gm...>]

Wolfgang S. Kechel wrote:

>> I like to open a discussion on the following problem:

>> 1. Subclassing
>> Create a subclass of Interp. Unfortunatly, the code need to be cluttered
>> with casts to the new subclass (i.e. in the implementation of Commands
>> or when passing around the interpreter).
>> Unfortunatly, this approach is bad when loading modules, since a module
>> can not change the class of an interpreter to a new subclass.
>>
>> 2. Maintain a map of data attached to a specific interpreter
>> The problem with this approach is that once data has been inserted to
>> the map with the interpreter as key and the data as value, there exists
>> a reference to the interpreter in the map and one one is done with the
>> interpreter, he needs to cleanup the date.
>> A destroy-method on the interpreter would be nice to indicate that the
>> indicator is no longer needed. 'destroy' should unload all modules
>> loaded into the interpreter (a task that requires that loaded modules
>> are remembered in every interpreter.

If it were in the Interp class itself, there wouldn't be an external
reference to it, would there?

>> I used the latter approach, but I am not quite satisfied with it. Is
>> there anybody out there who has a better idea? Maybe making Intrep an
>> abstract class or even an interface might help?

I guess we could do that too, but I'd like to at least consider the
possibility of adding what's missing.  Also, any concrete examples of
the overall problem to solve help me to visualize what needs doing, too.

I added 'auxdata' to Interp:

    public Hashtable auxdata;

We'll see if the same compile fix that helps in dealing with 'commands'
applies here...

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/