[Cuis-dev] Thoughts about symbols

[Andres Valloud]

Hi,

> I don’t think the current design is wrong, or that anything is broken… 
> but I’m no expert on unicode. My post was more about thinking together 
> about the nature of symbols.

See, that's the point.  If you look at the nature of symbols, you want 
to see how they are represented and what they mean.  But that means you 
have to look at strings and characters.  And that leads you to code 
points and how they are interpreted.  Symbols are not just singletons.

The image is currently broken as noted in the email you responded to.

> Anyway, the code duplication is minimal, 
> and could be solved by other means (moving some methods up to 
> CharacterSequence, for example, although they make more sense for 
> symbols than for general strings).

That's going to hurt because you will have to go through two barriers of 
"should not implement" or equivalent, each time a push up goes from 
symbol past string.

> Also, as I suggested, making Symbol 
> just a subclass of object with an instance variable for the 
> representative string solves this “problem” without introducing more 
> complexity (new classes to represent sequences of codepoints separate 
> from sequences of characters, etc)

This doesn't quite work without code duplication because the system 
expects instances of Symbol to behave as a string, and also as a 
collection.  It would seem odd to have to remember which subclasses of 
Object behave like Collection each time you add a convenience method.

This design problem has been solved for at least 30 years, the solution 
pattern is generally called "composition and delegation"...

Andres.