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
>
>