"Abstract" and "Basic" classes (was: Re: [BUG] Various packages in Squeak 3.8 (eCompletion, Comanche, Seaside...))

Andreas Raab andreas.raab at gmx.de
Fri Apr 8 21:30:39 UTC 2005


This raises the interesting question if we shouldn't do some renaming, 
say "AbstractString" into "String" and "String" into "ByteString". The 
reasoning being that String is a concept (that of containing characters) 
not an implementation (that of containing 8 bit latin1 encoded 
characters) and it encourages using the generalization since most people 
are used to thinking in terms of "String" modifications. Besides, I find 
names beginnign with "Abstract" or "Basic" *horrible* - it means someone 
hasn't really thought about what the name of the generalization is (or 
chosen an outright wrong name so that you have to stick the modifier in 
front of it) - can you imagine us using "AbstractCollection" instead of 
Collection, "BasicNumber" instead of Number, or "AbstractBehavior" 
instead of Behavior?

Horrible. Just horrible. It follows from the abstract concept 
represented (Number, Collection, Behavior) that these are abstract 
entities that cannot be instantiated and the concrete subclasses have 
concrete names (Integer, Set, Class).

I think we should really get away from using these meaningless "basic" 
and "abstract" versions for names and rather start thinking about *good* 
names.

Cheers,
   - Andreas

PS. I'm not fixed on doing the above rename - it would be equally fine 
with me to change AbstractString to CharacterArray or somesuch which 
would be somewhat more in line with subclasses of SequenceableCollection 
having a <Foo>Array like name.

Pavel Krivanek wrote:
> Various packages like eCompletion etc. add some methods to String class. In
> Squeak 3.8 it may cause DNU if MultiString is used.
> 
> So many enhancements of String have to be added to AbstractString class
> instead.
> 
> -- Pavel
> 
> 
> 




More information about the Squeak-dev mailing list