Odd 'dead' primitives
Tim Rowledge
tim at sumeru.stanford.edu
Fri Oct 18 23:00:56 UTC 2002
"Andreas Raab" <Andreas.Raab at gmx.de> is claimed by the authorities to have written:
> Tim,
>
> [primitive: 123]
> > Ah yes, of course; fortunately I'm aiming these
> > changes at the VI4 so backwards compatability isn't
> > much of a problem. Do you remember what needs doing
> > in the image to remove it?
>
> Just replace these methods by a call to #value and remove all the
> primitive failure code. It's just unneeded.
Well yes, but I see there are two explicit users of
#valueUninterruptably for example - CRDictionaryMorph (dumb name for a
class)>acceptCapturing and MethodContext>cachesStack whereas #ensure:
and #ifCurtailed: only use it if the prim fails. I can't quite see why
those explicit uses exist. Looks to me like they should simply refer to
#value.
#ensure: and #ifCurtailed: (this one puzzles me - doesn't look like it
will work if the prim is not there, and if it is, then it seems to be
identical to #ensure:) can drop the send of valueUn... and #valueUn...
can be deleted and #return: can just have the first line be
handlerHomeContext _ nil.
right? What have I missed?
[snip]
> That'd be very worthwhile but it's a question of how much time you have
> to play with this.
Oh, enough.
tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Never trust a computer you can't throw out the window. - S. Hunt
More information about the Squeak-dev
mailing list
|