Stef,

In order to support easier migration it might be better to have something
like

Object>>deprecated: aBlock

e.g.,

Smalltalk>>browseAllSendersOf: aSymbol
	^self deprecated:[SystemNavigation browseAllSendersOf: aSymbol]

This would make it easier for people to find potential problems while
migrating things. It would also make a nice package to have "just the
deprecated" things you can use to (for example) run or port code that has
been written for older versions. Object>>deprecated: can then raise an
exception which (if it resumes) evaluates the block. So if you're in a
desparate hurry you can get your system running fast and once you got a
little time you can fix all the places.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Stephane Ducasse
> Sent: Friday, May 09, 2003 12:30 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Harvesting and deprecation
> 
> 
> Hi brent
> 
> In KCP we choose to let the deprecated method but raise an exception 
> (self error:)
> with an explanation telling which method should be call instead.
> 
> Noury suggested that we introduce an exception DeprecatedException so 
> that we can
> trap them specifically.
> 
> So we do not follow the deprecated pattern a la java in the 
> sense that 
> we do not say in the future this method will be deprecated and still 
> let it. We were thinking that we could
> go faster than way.
> 
> But I like your idea to add deprecated in ProtoObject.
> 
> For now I was doing that this way
> 
> allBehaviorDo: aBlock
> 
> 	self flag: #deprecated.
> 	self error: 'This method is deprecated please use 
> SystemNavigation>>allBehaviorDo:'
> 
> 
> 
> Stef
> 
> On Friday, May 9, 2003, at 09:45 AM, Brent Pinkney wrote:
> 
> > OK,
> >
> > I have been following the harvesting thread for a while now 
> and have 
> > been called apon to revide my DateAndTime stuff. This 
> removes a couple 
> > of yucky methods that have crept into Date and Time.
> >
> > What is the preffered method of deprecating classes and methods ?
> >
> > In the full image of yore it was relatively simple. In the 
> SqueakMap 
> > era, how do I know I can cull a redundant or yucky method/class ?
> >
> > The alternative for endless backward compatibility seems to 
> be a cop 
> > out. A tight lean elegant implementation is important.
> >
> > I propose calling ProtoObject>>#deprecated in the to be deprecated 
> > method. Two versions later this should cause and exception. 
> > Alternatively move the methods to the deprecated category, although 
> > this may not play nicely with DVS.
> >
> > Ideas ?
> >
> > Cheers
> >
> > Brent
> >
> >
> 
>