[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
stubble message continued....
- To: <michael@xxxxxxxxxxx>
- Subject: stubble message continued....
- From: Mark S. Miller <vlad!mark>
- Date: Fri, 27 Jul 90 15:26:04 PDT
- Cc: <xtech@xxxxxxxxxxx>
- In-reply-to: <Michael>,33 PDT <9007271141.AA20770@xanadu>
Some comments on the code:
"TextyCommXcvr::send(Heaper*)" also needs to check for "obj == NULL"
right at the top. We just forgot--this case is already dealt with
correctly in the existing code.
"TextyCommXcvr::receive(Category*)" should declare it's "recipe"
variable "WPTR(HeaperRecipe)" instead of "WPTR(Recipe)". The line:
recipe = getRecipe (className);
should instead read:
recipe = CAST(HeaperRecipe,getRecipe (className));
Then the abstract superclass Recipe would not declare any "make"
methods. The Var & Heaper "make" methods which Michael describes
would be declared starting in VarRecipe & HeaperRecipe respectively.
(This is all in accord with the meeting.) Note that we shouldn't call
these classes "RecipeVar" and "RecipeHeaper" because the first isn't
itself a Var object.
Date: Fri, 27 Jul 90 04:41:33 PDT
From: xanadu!michael (Michael McClary)
...
Typical sendProxyTo() for copy part of a mixed copy/proxy object
(say, a by-proxy class built on a by-copy base class):
A by-proxy class built on a by-copy base class must itself be a
by-copy class as well as a by-proxy class. This is because it needs
its own by-copy constructor (which is declared by the COPY(..) macro.
(Its COPY(..) section can of course be empty.)
Which brings up a related point: with the receive method we wrote, a
newly created proxy object is never directly informed of its objNum.
This is actually ok, as it can ask the Entry that it is passed. I
suppose it should also ask the Entry for the CommHandler (after
casting the Entry to a CommHandlerEntry?).