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.