[Cuis-dev] Thoughts about symbols

[Luciano Notarfrancesco]

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> 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
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241201/74a16d7f/attachment.htm>