[Cuis-dev] Thoughts about symbols

[Andres Valloud]

The design is not great because it induces copy pasting in other places 
of the system via the class hierarchy duplication.

Of course, as you say, it's just a bug.  But going that route means 
every design is ok because any problems a design creates are just bugs. 
There is more to it than that.

On 12/1/24 4:41 AM, Luciano Notarfrancesco via Cuis-dev wrote:
> I don’t want to be forced to defend my idea, because it’s not even an 
> idea that I feel strongly about, just wanted to run it through the 
> people here… But, if the problem is that the image assumes a lot of 
> string protocol in symbols, you could make Symbol subclass of 
> CharacterSequence instead of Object. And yes, I saw the bug you 
> mentioned in your mail, but I don’t think that means the design is 
> wrong, it’s just a bug..
> 
> On Sun, Dec 1, 2024 at 18:12 Andres Valloud via Cuis-dev <cuis- 
> dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
> 
>     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.
>     -- 
>     Cuis-dev mailing list
>     Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>     https://lists.cuis.st/mailman/listinfo/cuis-dev <https://
>     lists.cuis.st/mailman/listinfo/cuis-dev>
> 
>