Why Interpreter isa ObjectMemory
PhiHo Hoang
phiho.hoang at rogers.com
Sun Feb 24 22:21:05 UTC 2002
Tim Rowledge <tim at sumeru.stanford.edu> wrote:
>
> "PhiHo Hoang" <phiho.hoang at rogers.com> is claimed by the authorities
> to have written:
> > I read through the missing chapters of the Blue Book but miss
the
> > point why Interpreter is a subclass of ObjectMemory.
>
> It makes it simpler to generate the single interp.c file.
Anthony added:
> Since message sends in Interpreter and ObjectMemory are translated to
C function calls,
> which does no receiver dispatching, the receiver always has to be
self, hence the choice
> to make ObjectMemory a superclass.
I am a bit confused. According to the NuBlue book:
anObject frobosinate
is translated to
frobosinate(anObject);
and
anObject frobosinateWith: aWidget
is translated to
frobosinateWith(anObject, aWidget);
and
anObject frobosinateWith: aWidget andWith: anotherWidget
is translated to
frobosinateWithandWith(anObject, aWidget,
anotherWidget);
Maybe it is the other way around, because the choice was made to
make Interpreter a subclass of ObjectMemory. And since there is no real
ObjectMemory object, all message sends from Interpreter to ObjectMemory
ends up as a send to self ?
Also, there is no real Interpreter object either, so all message
sends from any other objects to Interpreter (and ObjectMemory) is via
InterpreterProxy:
interpreterProxy integerObjectOf: 17
is translated to
interpreterProxy->integerObjectOf(17);
> If you separate ObjectMemory out to another object you will have to
> update the CGenerator so it knows that message sends to objectMemory
> are just regular function calls.
> You will still have to maintain
> that method names are unique across both Interpreter and ObjectMemory,
> unless you put them in seperate C modules and utilize private
functions.
I think I settle for a design around a MetaObjectMemory.
Thanks for your enlightenment.
More information about the Squeak-dev
mailing list
|