Sigh... I was nearly finished a reply when my X server crashed!!! Now I 
have to try to remember what I said...

Obviously I can change the method on Object for my own use, but that is 
not the issue.  The idea of deprecation is that developers of a package 
can easily find the deprecations and remove usages of them, but in the 
meantime, non developers (and I mean non-developers of a particular 
package, not people who don't develop at all) can keep using the code.

At the moment, we are beating *everyone* over the head with deprecation 
instead of just developers of a package.  If the messages went to the 
transcript instead, developers could find them but users could ignore 
them.  Another option might be to have a config flag to control whether 
a warning should be brought up so that developers could turn it on as 
desired.  But even then, I might be a developer of one package but I 
don't necessarily want to get a pink dialog every time I make a certain 
call to another package I am using that I don't develop for.

The issue is about control.  Currently, for example, Monticello contains 
code that conditionally checks whether #newChanges: is defined on 
SystemDictionary or ChangeSet.  Why?  Because the deprecation code in 
#newChanges: makes Monticello unusable in 3.6 and the only way to have 
the code work in both 3.5 and 3.6 is to add our own conditional code. 
If the deprecated method worked silently until 3.7, we could use the old 
method for a period of time which would allow the code to work in 
multiple versions and could gradually phase the deprecated code out.  As 
it is, we just have to bypass the deprecation messages because they are 
too intrusive for a Monticello user.

Julian

ducasse wrote:
> Hi julian
> 
> The idea of the notification the way it is is to really warns the people 
> in annoying manner.
> Now do not tell us that you cannot simply just change the method into 
> Object, to do what you want
> :)
> 
> By the way doug if you change the name of the method I was thinking that 
> deprecated is better than deprecation :)
> 
> On Mardi, sep 16, 2003, at 18:53 Europe/Zurich, Julian Fitzell wrote:
> 
>> Daniel Vainsencher wrote:
>>
>>> I used the SM version of the Refactoring Browser for all my development,
>>> at whatever is the alpha version. It currently uses deprecated methods
>>> (which can be proceeded, or patched individually, and might be fixed
>>> soon collectively).
>>
>>
>> Ugh... speaking of which... it seems to me that a deprecated method 
>> isn't really deprecated if it pops up a dialog and halts processing; 
>> it might as well be removed.  It's not much better than getting a DNU 
>> really (well, ok, you get a more descriptive error and you *can* 
>> continue).
> 
> 
> EXACT!
> 
>> But couldn't we have it just output a message to the Transcript that 
>> the message is deprecated and then continue normally? It seems to me 
>> that the point of deprecation is that software continues to work 
>> during a period of time where the developer can find the deprecations 
>> and change them.
>>
>> The current situation doesn't really seem to leave software using the 
>> deprecated methods in a "usable" state.
> 
> 
> Ugh???
> 
>> Perhaps this would even be worthy of one tiny last change to 3.6 
>> before final?  Or perhaps I'm the only one who sees it this way...
> 
> 
> At least I'm not and the guy that proposed the mechanism that way too.
> 
>>
>> Julian
>>
>>
>> -- 
>> julian at beta4.com
>> Beta4 Productions (http://www.beta4.com)
>>
>>
>>
> 
>