Why Strings as Classes?

[JAnderson]

Benji Smith wrote:
> In another thread (about array append performance) I mentioned that 
> Strings ought to be implemented as classes rather than as simple builtin
> arrays. Superdan asked why. Here's my response...
> 
> I'll start with a few of the softball, easy reasons.
> 
  > But much more important than either of those reasons is the lack of
> polymorphism on character arrays. Arrays can't have subclasses, and they 
> can't implement interfaces.

I don't think polymorphic strings is right for D strings.  This is the 
sort of thing a lib could implement but D should (and does) provide the 
basic components of which to build more complex components.  You can 
already extend D strings by using strings as a component, if it its 
necessary.

I don't want all this extra overhead in the primitive array type.  It 
seems to me a classic case of feature creep, pretty soon we have 
something that has been designed for all but its original purpose.  I'm 
ok with having features like hash caching as long as they can be 
implemented without changing the core mechanics of the primitive.

To me its not even correct design to inherit from a concrete class 
(there are quite a few books on that, Effective C++ talks about it a bit 
and so does Herb/Alexandrescu 101 Coding standard book).  I think, there 
are *much better* ways to handle this sort of thing.  Personally I don't 
want to encourage that sort of design.

-Joel