0001733: [ENH][FIX] String-upToDep-huma

Notes
(0002485 - 801 - 907 - 953 - 1054 - 1054 - 1054) mzimmerm 08-22-05 05:42	tomkoenig@mindspring.com " ( [er][et][sm][cd] Recommend not including because it does its job too well ) 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. 0006537. 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. "

(0002486 - 1133 - 1352 - 1394 - 1495 - 1495 - 1495) mzimmerm 08-22-05 05:45	Peter van Rooijen <peter@vanrooijen.com>: " > 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. 0006537. > 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. "

(0002487 - 239 - 291 - 330 - 330 - 330 - 330) mzimmerm 08-22-05 05:47	Lex Spoon <lex@cc.gatech.edu>: " If there are 80 uses in Tom's image alone, then there are surely many others in the various projects on SqueakMap. How about we dump the deprecation entirely? The name seems thoroughly enshrined. "

(0002488 - 87 - 87 - 87 - 87 - 87 - 87) mzimmerm 08-22-05 05:50	When moving this item from BFAV to Mantis, verified the changeset installs in 3.8-6665.

(0002550 - 179 - 185 - 185 - 185 - 185 - 185) ducasse 08-27-05 20:36	I checked in visualWorks copyUpTo: is defined on sequenceableCollection, upTo: on stream. I think that to include this changes, all the senders should be changed to use copyUpTo:

(0002551 - 179 - 185 - 185 - 185 - 185 - 185) ducasse 08-27-05 20:36	I checked in visualWorks copyUpTo: is defined on sequenceableCollection, upTo: on stream. I think that to include this changes, all the senders should be changed to use copyUpTo:

(0004055 - 11 - 11 - 11 - 11 - 11 - 11) MarcusDenker 02-24-06 21:09	in 3.9a7003

Issue History
Date Modified	Username	Field	Change
08-22-05 05:40	mzimmerm	New Issue
08-22-05 05:40	mzimmerm	File Added: String-upToDep-huma.cs.gz
08-22-05 05:42	mzimmerm	Note Added: 0002485
08-22-05 05:45	mzimmerm	Note Added: 0002486
08-22-05 05:47	mzimmerm	Note Added: 0002487
08-22-05 05:50	mzimmerm	Note Added: 0002488
08-27-05 20:36	ducasse	Note Added: 0002550
08-27-05 20:36	ducasse	Note Added: 0002551
02-24-06 21:09	MarcusDenker	Status	new => closed
02-24-06 21:09	MarcusDenker	Note Added: 0004055
02-24-06 21:09	MarcusDenker	Resolution	open => fixed
02-24-06 21:09	MarcusDenker	Fixed in Version	=> 3.9

Relationships