[Vm-dev] Why Interpreter subclass ObjectMemory ?

[David T. Lewis]

On Mon, Feb 15, 2010 at 03:24:52PM +0100, Mariano Martinez Peck wrote:
>  
> On Thu, Feb 11, 2010 at 1:55 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> > On Thu, Feb 11, 2010 at 10:19:34AM +0100, Mariano Martinez Peck wrote:
> > >
> > > I ask without knowing anything of the background or context. I have just
> > saw
> > > it and I cannot understand very much why it is like that. I ask myself if
> > > composition would be better.
> > > Probably is something related to SLANG, but I don't know.
> >
> > Yes, that is right. Organizing the Interpreter as a subclass of
> > ObjectMemory
> > makes things simpler for the C code generator, which creates one C module
> > for all the methods in Interpreter and its superclasses. I think this was
> > probably a case of doing the simplest thing that could possibly work.
> >
> 
> 
> Thanks Dave. I am trying to understand, that's all. So...suppose I want to
> have an instance of ObjectMemory as an instance variable of Interpreter and
> delegate to it instead of inherit, this won't work with SLANG?   I image
> that inter.c has both Interpreter and ObjectMemory because of the
> inheritance. Then, if I do what I said, SLANG, or the translator, or the
> someone I don't who, cannot correctly put everything together in a inter.c
> in the same way it is done right now ?

Mariano,

I suspect that it probably can be made to work, although I have not
looked into it carefully. I would encourage you to experiment with this
if you have an interest in it, and report back if you find a suitable
approach. I suspect that figuring out how to make Interpreter and
ObjectMemory delegate to one another may to be too big a problem to
solve at first, so maybe you can start with some smaller class that
you want to "mix in" to the Interpreter/ObjectMemory hierarchy, to
be generated into the interp.c output file. If you get this working,
you may be able to extend the idea to the interpreter itself.

Dave