"Abstract" and "Basic" classes
Andreas Raab
andreas.raab at gmx.de
Sun Apr 10 04:42:05 UTC 2005
Hi Yoshiki,
>>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.
>
> I've done that several times for 2.4, 2.8 3.0, 3.2, 3.6 and 3.8, but
> it just got harder to keep up...
I can imagine ...
>>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).
>
> Guilty as charged. The basic strategy is somewhat confused, since
> the way the methods are "lifed" up to AbstractString from the old
> String, sometimes the implementation at AbstractString is used, but in
> some other cases, it is declared as subclassResponsibility and the
> subclasses define the method.
No charge here - I just noticed that since many of these methods are
implemented in three classes it makes it a *lot* harder to see if
there's an actual difference or if these guys basically do the same
(it's obvious if you see it only in one place since it'll be a trivial
yes or no). That's why meant that a little refactoring to minimize the
different implementations would be really helpful (for example, just
figuring out how to merge the compare:with: methods would allow one to
unify practically all of the comparison methods which I think amount for
roughly half of the differences).
>>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:
>>
>>...
>>
>
>
> After these steps, we should replace all the #== equality check for
> characters with #= for the similar reason as Numbers.
Argh. This isn't fixed yet? I thought it was...
You know ... is there a way of forcing the system to use MultiStrings
exclusively, no matter what the cost? I think that most of these issues
are not fixed since unless there's some guy actually using them most of
the developers never think about it.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|