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