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