At 19:19 -0600 3/16/00, Maurice Rabb wrote:
>
>I recognize the importance, and high degree of interdependence of String in Smalltalk.  Moving String from under Collection is not that difficult, however finding every place that a string is used as a collection is non-trivial.  (What is the best/easiest way to do this?)  Initially the collection protocols that are used by strings could be copied to String in it new place in the hierarchy.  All such methods would be commented as being discouraged, and recommend the use of the idioms: 'aString contents someCollectionMethod', or 'aString contentsDo: aBlock'. (#contents, #characters, whatever!) After a few revs of being weaned, perhaps we could eliminate the direct collection protocols from String.

Since strings are used as collections all the time, and they *are* collections of characters, why do you want to do away with the collection protocols? At first hearing, it's as if you are proposing to move Float from the number hierarchy and remove all those silly adds and subtracts and isNANs!

I just looked at much of the implementation of string and found many 'self do:', 'self inject:...", and other protocol you want to omit. Something so simple as asLowercase does a 'self do:'. It isn't just a few users who need to be weaned, it's String itself that is full of self assumptions.  :)

Further, a large number of methods in String assume that strings are indexable and index self directly, or send a #copyReplaceAll:with: or similar messages which assume that self is indexed. But #copyReplaceAll:with: is another annoying method inherited from collections; there are a lot more.

But basically, why do you want to take away a lot of function from String? Maybe it is in the wrong place in the hierarchy, and the hierarchy needs to be refactored, but String is a perfectly fine collection. Why do you want to break it?


I did try to follow the threads back from this message, but they've been going on for a while under several names and on other topics; maybe I missed a perfectly fine explanation. If so, can someone point me to it?

Puzzled in Connecticut...

Dave
_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.