Just to be clear:
	
TransferMorph>>#dropNotifyRecipient does not seem to be used in the 
trunk image: it's used in my own (old) code; the point here is that I 
would rather like an error due to the fact that #dropNotifyRecipient has 
actually been deprecated and is just missing, or even an error telling 
me it's going to be deprecated soon, better than having an artificial 
error looking like a leftover from a clean-up operation.

Actually now that I think of it, the best would be a specific Error or 
Warning telling the method is on the death row, plus a preference 
allowing all these exceptions to be ignored (this would be by default) 
or raised (this would be "package transition mode", which I turn on when 
I want to see if my code uses deprecated stuff or not).

Does it make sense ?

Stef


> When moving a method from one category into the other, I ran into a
> strange error:
>
> 	TransferMorph>>#dropNotifyRecipient
>
> instead of doing its job do
>
> 	self isThisEverCalled
>
> So: yes, it is called, and plus: I find it rather rude to break my
> workflow with such questions.
>
> Could we remove all #isThisEverCalled sends from the release image ?
> Because I don't think it's the responsibility of the end user to help
> developers know what should be deprecated. Especially by raising a
> debugger at their face...
>
>
> Stef
>
>
>