A 'slightly weird idea: Can we warn, say, every 10 methods instead of 
every single one?

On Tuesday, Sep 16, 2003, at 20:34 Europe/Zurich, ducasse wrote:

>
> 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)
>>>>
>>>>
>>>>
>>
>>
>>
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org