Deprecation (was: Refactoring Browser (was: About
KCPandautomatic initialize))
Roel Wuyts
wuyts at iam.unibe.ch
Wed Sep 17 08:06:37 UTC 2003
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
More information about the Squeak-dev
mailing list
|