On 2009-12-15, at 1:22 PM, Eliot Miranda wrote:

> 
> On Tue, Dec 15, 2009 at 12:55 PM, Michael van der Gulik <mikevdg at gmail.com> wrote:
>> 
>> It is not uncommon to have some CompiledMethod not installed in any
>> methodDictionary.
>>    CompiledMethod allInstances reject: [:e | e isInstalled]
>> Accessing associated source would become impossible in this scheme
> 
> Where would these exist? How would they be used?
> 
> 1.  When one redefines a method in the browser existing activations of the old method are still potentially visible in the debugger.  If you try e.g.
> 
> Object methods for recompilation
> haltInRecompile
>    (self class whichClassIncludesSelector: thisContext messageSelector) recompile: thisContext messageSelector.
>    self halt
> 
> the halt will occur in the old version of haltInRecompile.  The Debugger may show the method as e.g. Object>>unboundMethod.
> 
> 2. if a package system supports overrides it is conceivable that the overridden versions of methods are kept around in the event that unloading a package will remove the overrides and need to reinstall the overridden ones. At least that's what we did in VisualWorks.
> 
> 3.  if the system supports breakpoints in methods it is conceivable that an unbreak-pointed version of the method is squirrelled away while the break-pointed version (which may contain a hidden send of halt or breakpoint or whatever) is installed in its place.  At least that's what Terry Raymond's Professional Debug package does for VisualWorks.
> 
> There may be other examples (John Brandt's MethodWrappers?).

SystemChangeNotifier. When a new version of a method is installed, SCN notifies all it's clients, supplying both the old method and the new method. Only the new method is actually installed in the class' method dictionary. 

Colin