String refactoring

Andreas Raab andreas.raab at gmx.de
Tue Apr 12 06:17:49 UTC 2005


>>Suggestions?
> 
>   Oh, well.  Probably we could do the bug compatible behavior for the
> older projects.  Also, when designing the future systems, avoiding the
> dependency on any sort of upper/lower case distinction/manipulation.

Well, no. This has very little to do with upper/lower case manipulation. 
The problem is that there are currently seven methods in MultiString 
which are flagged #toBeImplemented but the thing they absolutely need to 
do (and which they don't) is to be consistent with their latin1 
interpretations. Even though all of these methods might be broken for 
some characters or others this is less problematic than having 
inconsistent implementations where the will results differ if you just 
happen to choose a different representation for intermediate results, e.g.,

tst := String with: $a with: (Character value: 512).
(tst copyFrom: 1 to: 1) capitalized, (tst copyFrom: 2 to: 2)
	= tst capitalized
=> false

For a workaround: This actually seems a little harder to get right than 
one would imagine (partly because of the above problem with intermediate 
results). I tried quickly to use hack like #eToysCapitalized which would 
replicate the broken behavior but there are some really grave issues 
with this - we're now basically enshrining the broken behavior forever, 
since noone will ever be able to back out of that usage.

Changing the code itself in the project also seems to be far from 
trivial - for one thing we're not getting to the source code of the 
scripts (this would have allowed us to use simple string replacement), 
the tiles refer to the already broken name, and we need to get to the 
slot info in the player to construct the "proper" spelling. But even if 
we did that I am still not a 100% sure we could do fix all the places 
where this is used.

This is a really hard problem... I dislike option 1 because it's so 
fundamentally flawed, and I dislike option 2 because it's so hard to 
implement. Sigh. I just wished you hadn't removed that code ...

Cheers,
   - Andreas



More information about the Squeak-dev mailing list