<div dir="auto">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..</div><div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 1, 2024 at 18:12 Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">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 <a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a> <a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a> </blockquote></div></div>