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
|