"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