<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 1, 2024 at 17:14 Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></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)" dir="auto"><br>What triggered this conversation was the observation that the current <br>
string implementation strategy has side effects.  Since storage of code <br>
points is fused with its interpretation, well then, what are we going to <br>
do with symbols?<br>
<br>
Currently we have an expedient way out: make a symbol subclass for each <br>
string class.  But this leads to duplication.  The reason for this <br>
duplication is that storage and interpretation are fused.</blockquote><div dir="auto"><br></div><div dir="auto">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. 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). 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)</div></div></div>