>
> 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.

It would be nice to identify these because this is clearly idioms like 
that that leads to fragile system and are often hacks.
Ok I read further your email and we agree on that.

>
> 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).

Sounds quite big effort.... :(

> 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).

self flag: #...

>
> 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.

True. I raised this issues several times but the answer was not clear.
My suggestion as KCP person, is that the only way to lower frustration 
is that:
	- we try to "document" the changes using test
		We started to do that in KCP to make sure that one other fixes would 
not break what we did
		but we stopped rapidly because we were lazy.
		we could have a test that say no String ref in Classes: ....
		but for the other groups this may be difficult.
	- the groups should work on the latest alpha image and commit their 
changes fast (if possible)
	else I do not see how we can proceed (except using classboxes :)).
		Right now the situation paralyzed me, because I do not want to break 
code of other
		but this simply prevent me to do what I would like to do.

at SCG we are always thinking that we invent a way to work with 
multiple version of a system without breaking existing
clients. Classboxes are a step in that direction. May be we (scg) 
should try to run a controlled experiment to see
how far we can go for real (with binary saved...).

Stef