[Vm-dev] Why Interpreter subclass ObjectMemory ?

David T. Lewis lewis at mail.msen.com
Tue Feb 16 01:17:18 UTC 2010

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 ?


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.


More information about the Vm-dev mailing list