At the risk of sounding stupid, I'm gonna ask a novice question (being 
new to this whole thing): Is this a Squeak-only issue or is it present 
in any (all) other Smalltalk VM implementation?

Granted, I'm following your message and agree that there are serious 
implications to making this change. However, it's hard for me to grasp 
that a language so mature as Smalltalk is having these kind of 
issues/debates.

Sorry if this has been asked before.

Thanks,
Daniel

On Apr 9, 2005, at 11:30 PM, Andreas Raab wrote:

> stéphane ducasse wrote:
>> So does someone step and do it?
>
> This is not an easy task and *please* whoever is tempted to "just do 
> it" hear me out about what needs to be done or else we will end up 
> with another major desaster because of a total misunderstandings about 
> the large scale implications of that change.
>
> There are at least three issues to keep in mind:
>
> a) All references to String, AbstractString and MultiString need to be 
> checked to see if they will be okay to remain the way they are. This 
> is a daunting task - in a full 3.8 image there are roughly 850 
> references to String alone.
>
> This is a critical problem - right now, just renaming and recompiling 
> the system will break immediately due to various "foo isKindOf: 
> String", "foo isMemberOf: String", or "foo class == String" and more.
>
> b) It seems there is quite some confusion in AbstractString, String, 
> and MultiString as far as the protocols are concerned. For example, 
> consider  the duplication of the comparison protocol - clearly that 
> isn't needed. Some parts are outright broken such as 
> AbstractString>>indexOf:startingAt: which will fail for multi byte 
> strings (it always uses the ByteString version).
>
> From looking over various places it gets clear that this problem makes 
> it a lot harder to track when the (intentional or not) references to 
> AbstractString vs. String need to be fixed.
>
> c) Any strings that are stored in binary files (in particular in 
> projects) will be affected by this. This will be a major issue and 
> might affect everything up to the ability to load your latest map from 
> SM (which IIRC, is being distributed via ImageSegment and that would 
> indeed be affected by it).
>
> Possible plan of action: As far as I can see from looking over the 
> changes a plan of action does need to address the above three issues 
> (and some that I haven't seen yet). It requires:
>
> a) Some internal cleanup of the String classes to make sure that the 
> interface is totally consitent even on the class side and avoid 
> confustion about what is being used where and when. Just adding 
> #isByteString, #isMultiByteString would be tremendously helpful for 
> the next steps.
>
> b) Reduce the dependency on class names by removing them wherever 
> possible. E.g., make sure that all of the roughly 1k uses of String 
> and friends have been reviewed and either:
> - being considered fine (say, String streamContents:[], String new 
> writeStream ...)
> - rewritten from "foo isKindOf: String" to "foo isByteString" (if that 
> is what is meant) or "foo isString" (I've seen both)
> - marked for the rename so that they are easier to find and to review 
> (such as ByteArray>>asMultiString which indeed would need to be 
> changed to whatever the new name of the wide string class is).
>
> c) Figure out what to do about binary files *BEFORE* the rename 
> happens and prepare appropriate means of converting the existing 
> objects.
>
> Once all of the above is done you may *try* to rename the string 
> classes (which in itself is a trivial exercise) and *then* you may 
> *try* to recompile your system and see it break in new and unforeseen 
> ways. And once you got this done you're ready to experience all of the 
> hazzles of dealing with stuff stored in external form.
>
> Cheers,
>   - Andreas
>
> PS. Some of the above would be fairly straightforward but it raises 
> another question: That of how to integrate even more changes across 
> the board with changes produced by Morphic splitters vs. Kernel 
> refactorings vs. ToolBuilder vs. String use. So far, I haven't even 
> seen a plan on how to deal with these issues and that leaves me 
> somewhat doubtful if it's even worth spending time on it.