On 2012-08-23, at 19:04, Frank Shearar wrote:

> On 23 August 2012 17:35, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> On 2012-08-23, at 15:07, Frank Shearar wrote:
>> 
>>> So the organizer loses the reference because ObjectAsMethodWrapper
>>> calls #removeSelectorSilently:, which eventually calls
>>> ClassDescription >> #removeSelector:. It re-adds the now-unwrapped
>>> CompiledMethod to the method dictionary with #addSelector:withMethod:
>>> which eventually calls ClassDescription >>
>>> #basicAddSelector:withMethod:. However, this does _not_ add the
>>> selector to the organization's elementArray, and Bad Things Happen.
>> 
>> 
>> Why is removing necessary in the first place? Couldn't it just replace the compiled method?
> 
> Sure, you could. What I think of the canonical example of this stuff
> is TestCoverage, and it just does
> 
> TestCoverage >> uninstall
> 	reference actualClass methodDictionary
> 		at: reference methodSymbol
> 		put: method
> 
> (I'd rather use addSelector:withMethod: than this approach - I don't
> think it's an ObjectAsMethodWrapper's business to tinker directly with
> something else's method dictionary.)
> 
> frank


But at least this one would be atomic. Removing followed by adding puts the system into a potentially broken state while the wrapper is already gone but the original method is not yet installed.

- Bert -