Harvesting and deprecation

Stephane Ducasse ducasse at iam.unibe.ch
Fri May 9 11:53:46 UTC 2003


Hi andreas

Ok! I vote for! Am'I correct that the Object>>deprecated: aBlock
and the deprecated method could raise a warning.

We will issue some new changesets to fix all the deprecated methods
we did the other way.

On Friday, May 9, 2003, at 01:18 PM, Andreas Raab wrote:

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



More information about the Squeak-dev mailing list