Squeak already has private method support (was Re: FW: Pressu

Andrew C. Greenberg werdna at gate.net
Sat Feb 20 14:52:57 UTC 1999

Tim suggests:

> There are some bits available in the method headers  (or at least 
> there are if
> you use my NewCompiledMethod images) and one or more could be used to flag a
> method as private. The message sending code could check this flag and
> subsequently test the current reciever against the putative reciever of the
> message being sent. If they do not match, do something like #cannotReturn (or
> better yet do a proper exception raising) and work out what to do next.
> With several flags available, we could even consider reifying the several-
> levels-of-privacy idea Carl mentioned.
> The flag checking could conveniently be done in the cache loading routine and
> if we took the opportunity to 'fudge' the apparent primitive index we could
> essentially detect the private flag(s) at no cost in
> [internalE|e]xecuteNewMethod. Simply detect a primtiveIndex of some 
> ludicrously
> high number. By ORRing the flag into theprimitiveIndex we can keep the 'real'
> primitiveIndex if any is needed for the method.

Isn't the idea to avoid things that increase the overhead of message 
send?  Is the feature of precluding primitives at runtime (since 
compile-time is relatively straightforward) so valuable a feature 
that it justifies a separate check against a method header flag for 
EVERY uncached message send?

More information about the Squeak-dev mailing list