<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Marcel, Hi All,<br><br><div dir="ltr"><span style="background-color: rgba(255, 255, 255, 0);">_,,,^..^,,,_ (phone)</span></div><div dir="ltr"><br><blockquote type="cite">On Jul 12, 2022, at 11:48 PM, Marcel Taeumel <marcel.taeumel@hpi.de> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">Hi all --<div class="mb_sig"></div><div><br></div><div>What are your thoughts on String and Text. In GUI programming, it</div><div>is rather annoying to have to sprinkle #asText all over the code. It's</div><div>nice to have most important protocol shared between String and Text.</div></div></div></blockquote><div><br></div>As I wrote elsewhere, in VisualWorks Text & String provide much of the same api for manipulation (concatenation et al), search, etc, and differ for display.  Squeak is much weaker in this regard.<div><br></div><div>The architectural issue is that Text is a kind of string, and hence anything one can do to a string one naturally expects to be able to do to a Text.  Squeak should meet that expectation and currently it does not.</div><div><br></div><div>One of the issues is that functionality that could go in SequenceableCollection is put in String, I presume because people want something in String and don’t think abstractly enough about what that functionality is (an operation on sequences that they want to apply to character sequences).</div><div><br></div><div>I hope we can make it a medium term project to improve this part of the system with the related aims of moving functionality that apples to sequences up into SequenceableCollection, and making manipulation and search Apia polymorphic between Text and String.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr"><div><br></div><div>The recent change to only String >> #format: (see Collections-cmm.1016)</div><div>to support symbols as <span style="font-size: 10pt">placeholders indicates kind of a disagreement</span></div><div><span style="font-size: 10pt">in how Text should be </span><span style="font-size: 10pt">used in (GUI) code. Well, if some message is</span></div><div><span style="font-size: 10pt">not there in Text, it is </span><span style="font-size: 10pt">easy to find out. However, having a protocol there</span></div><div><span style="font-size: 10pt">with different details </span><span style="font-size: 10pt">feels rather challenging.</span></div><div><br></div><div>I accept that not all protocols are shared between String and Text.</div><div>I do not like inconsistencies of method implementations where the</div><div>message (and signature) is identical.</div><div><br></div><div>+1 for adding symbolic placeholders to Text >> #format: as well.</div><div><br></div><div>Best,</div><div>Marcel</div></div><span></span><br></div></blockquote></body></html>