[Vm-dev] Why Interpreter subclass ObjectMemory ?

Igor Stasenko siguctua at gmail.com
Tue Feb 16 02:10:19 UTC 2010


On 16 February 2010 03:17, David T. Lewis <lewis at mail.msen.com> wrote:
>
> 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.
>

There's always a way to start from a fresh approach by making own C
code generator,
which will take in account a delegation. Then port the interpreter
code to it and you done.
But it will cost you couple months of full-time work... ;)

> Dave
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list