On Mardi, sep 16, 2003, at 19:59 Europe/Zurich, Julian Fitzell wrote:

> 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.

I agree so propose something.

> 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.
>
Ok I see so propose something.



> 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)
>>>
>>>
>>>
>
>
>