Deprecation (was: Refactoring Browser (was: About KCPandautomatic
initialize))
Julian Fitzell
julian at beta4.com
Tue Sep 16 17:59:04 UTC 2003
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)
>>
>>
>>
>
>
More information about the Squeak-dev
mailing list
|