Really deprecates SequenceableCollection>>#upTo: to #copyUpTo:
This change set does exactly what it says it does (depreciates upTo:). However, I recommend not including it until a) we change how we respond to depreciated and/or b) we replace a sufficient number of the upTo: usages. Otherwise, this will make the image very hard to use. Tested in 3.9a. #6537. Right now, when we get a depreciate interrupt, clicking on proceed appears to not allow you to ignore the error. So IMO we can not afford to extend theuse depreciated ... There are 80+ usages of upTo:, including most notablely AbstractString and MultiByteString. When I tried to remove the one usage in BFAV, I found I couldnt until MBS was fixed, So BFAV became unusable.
tomkoenig@mindspring.com wrote:
This change set does exactly what it says it does (depreciates upTo:). However, I recommend not including it until a) we change how we respond to depreciated
It seems the word you and the OP are looking for is 'deprecated'.
Depreciation means a gradual reduction in value, deprecation means declaring obsolete.
and/or b) we replace a sufficient number of the upTo: usages. Otherwise, this will make the image very hard to use. Tested in 3.9a. #6537. Right now, when we get a depreciate interrupt, clicking on proceed appears to not allow you to ignore the error. So IMO we can not afford to extend theuse depreciated ...
Well, the response to using a deprecated feature would seem to need to be user-settable until the feature is actually removed. If the deprecation mechanism doesn't allow that, it's not much good.
There are 80+ usages of upTo:, including most notablely AbstractString and MultiByteString. When I tried to remove the one usage in BFAV, I found I couldnt until MBS was fixed, So BFAV became unusable.
squeak-dev@lists.squeakfoundation.org
-
humasect＠shaw.ca -
Peter van Rooijen -
tomkoenig＠mindspring.com