About deprecated methods
Joshua 'Schwa' Gargus
schwa at cc.gatech.edu
Fri Sep 12 05:13:35 UTC 2003
On Fri, Sep 12, 2003 at 12:48:06AM -0400, Doug Way wrote:
>
> On Thursday, September 11, 2003, at 10:45 AM, Joshua 'Schwa' Gargus
> wrote:
>
> >Hi Stef,
> >
> >I've had the same thought. I can't think of a downside to waiting two
> >versions before removing deprecated methods.
>
> The one downside to doing this is that keeping track of which methods
> will be deprecated when becomes more complicated. I guess we'd just
> need to keep a list somewhere of which methods had been deprecated two
> versions ago versus one version ago. Or somehow store that information
> in the method itself.
We could just make it a convention to add a comment stating when the
method was deprecated; the comment could be could be put right above
the deprecation call.
>
> Given that I'd slightly prefer to just wait one version. Most other
> languages (e.g. Java) wait just one version for deprecated methods to
> be removed. (I think most do, anyway.)
>
> We could wait two versions if others feel strongly about it, though.
>
> >After all, we haven't
> >been deprecating methods at all for years, and the world hasn't
> >exploded.
>
> That actually sounds like an argument to wait a shorter amount of time.
> We haven't been deprecating methods at all for years, in other words
> waiting "zero" versions, so we could probably survive waiting one
> version rather than two. :-)
Your logic seems perfectly sound :-)
>
> >On Thu, Sep 11, 2003 at 08:25:11AM +0200, ducasse wrote:
> >>
> >>I was thinking that we should let the deprecated methods over two
> >>versions to let the people the time to update. Do you think that this
> >>is silly? What is the period of time since 3.5?
>
> The period of time between 3.5final and 3.6final will be 5 1/2 months,
> barring any major problems. The time between 3.6 and 3.7 will probably
> be roughly the same. So methods marked as deprecated in 3.6 would be
> gone in 3.7, 5-6 months later.
You're saying methods deprecated in 3.6 would be removed when 3.7 becomes
final (or gamma)? Ah, that's different from what I remember you saying...
I thought you said deprecated methods would be removed at the beginning
of the 3.7 cycle.
The problem you cited earlier about when a method should be deprecated if
we wait 2 version seems to pop up again... how do you distinguish between
a method deprecated half-way through 3.6 and one deprecated just before
3.7 goes gamma?
> This seems like a reasonably long time
> to me. Although I suppose my Java example above might not be so good,
> since there's usually a year or so between Java releases, e.g. 1.3 to
> 1.4.... so maybe 5-6 months isn't so long.
>
> Speaking of deprecated methods, someone mentioned awhile ago that they
> thought the deprecation method should be renamed from
> #deprecatedExplanation: to just #deprecated:. I think this would be a
> good idea. The deprecatedExplanation: method name seems too verbose
> for such an important method... verbosity is okay for the names of
> rarely used methods, but for more commonly used methods shorter is
> often better, for example #do: and not #doBlock:. :-) Also in this
> case when seeing the #deprecated: method being used it's pretty obvious
> that the string being passed along is the explanation.
That sounds good to me.
> If we wanted to rename this method, the beginning of 3.7alpha would be
> a good time, especially if all of the senders are removed.
Or we would just deprecate the old method ;-)
Joshua
>
> - Doug
>
More information about the Squeak-dev
mailing list
|