<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Chris --<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">But until we do that, and whole hog like Eliot suggested,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> what we will have are *some* domain things that String</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> can do that Text can't -- a partial overlap.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">It's rather easy. Once we have a CharacterCollection, we can</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">finally see the special cases on String. The common stuff can be</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">moved up to then benefit both String and Text.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">In other words, an incomplete mess for an indefinite period of time.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Disagree. This kind of refactoring does not look too difficult. One</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">would not rename "String" to "CharacterCollection" but add the</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">latter between String/Text and ArrayedCollection. Then it can</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">remain backwards compatible 100%. Piece by piece, we can then</span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">start to remove the duplication and carve out the special cases</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">for String and Text.</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">> </span></span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">By removing all the domain stuff [...]</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">I think that we have a different understand of the term "domain"</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">here. Maybe you are worried about Magma. If so, please </span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">elaborate your concerns from that perspective.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">#format: was introduced to Text in 2019.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">And long overdue since at least 2015. ;-P Thanks again,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Christoph (ct) for adding it! It made GUI programming much</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">easier. I had that one in mind for many years now.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">I don't think updates to Text will or should occur except</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> when driven by specific need.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">The need is there. Code duplication is a problem for</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">maintenance and our small community. We should work</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">on that. Let's also learn from VisualWorks in this regard.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 14.07.2022 02:29:01 schrieb Chris Muller <asqueaker@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div dir="ltr">Hi all,<div><br></div><div>There are over 300 methods on String, and 100 on Text. Having Text be responsible for domain duty implies to blow up Text's protocol to around 4X of what it is now with copies from String or, worse, unique implementations requiring separate maintenance. The CharacterCollection idea at least makes it feel a bit less crazy. But until we do that, and whole hog like Eliot suggested, what we will have are *some* domain things that String can do that Text can't -- a partial overlap. In other words, an incomplete mess for an indefinite period of time.</div><div><div><br></div></div><div><div>The only other way besides introducing the common CharacterCollection superclass would be by *emphasizing* the separation of responsibility with Text by removing most domain methods from Text, but providing a path to the underlying string for the domain accessing behaviors. For example, both Text and String currently implement #string, so that's safe to send to either. By removing all the domain stuff, client code would be encouraged to send #string and go through that for those operations.</div><div><br></div><div>But Jakob's example of a piece of code wanting to #format: Text with another Text (with embedded attributes) shows a case actually needing that, so we're in a bit of a pickle.<br></div><div><div><br></div></div><div>#format: was introduced to Text in 2019. It's not being used with alphanumeric tokens, and that is just one of dozens of differences in capability between the two (due to the aforementioned incompleteness). Until a final decision on how to reconcile the two is made, I don't think updates to Text will or should occur except when driven by specific need.</div></div><div><br></div><div>Best,</div><div> Chris</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 13, 2022 at 10:45 AM Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de" target="_blank">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex;min-width: 500px">
<div>
<div dir="ltr">
<div id="gmail-m_-6721902426476195084gmail-m_-1864817551806924619gmail-m_6966876078167328350x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: rgb(0,0,0);font-family: Calibri,Helvetica,sans-serif">
<p>Hi all,</p>
<p><br>
</p>
<p>please keep in mind that Text >> #format: does more than the String equivalent as it also deals with attributes from both the receiver and the arguments. I think we should definitely support that.</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-6721902426476195084gmail-m_-1864817551806924619gmail-m_6966876078167328350x_divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif;color: #000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>><br>
<b>Gesendet:</b> Mittwoch, 13. Juli 2022 16:50:50<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] String & Text</span>
<div> </div>
</div>
</div>
<span style="font-size: 10pt"><span style="font-size: 10pt">
<div><br>
<br>
> On Jul 13, 2022, at 2:14 AM, Rein, Patrick <<a href="mailto:Patrick.Rein@hpi.de" target="_blank">Patrick.Rein@hpi.de</a>> wrote:<br>
> <br>
> To me String and Text should share all protocols related to dealing with a collection of characters. Text is a collection of characters with attached formatting information, thus Text "only" has to make sure that the attributes match whatever was done to
the character collection. I regularly get slightly annoyed when I try using a String selector with a Text object and get a DNU.<br>
> <br>
> Some time ago, someone proposed to have an abstract CharacterCollection as the superclass of both classes. I very much like that idea, as it would allow us to make the shared protocol explicit. We might not be able to factor much out to this shared superclass
but at least, we can have a clear expectation of what should work for both. This would also signify (somewhat) that the behavior should be consistent between the two. In practice I would probably expect Text behavior to be a superset of the String behavior,<br>
<br>
+1<br>
<br>
> but I am not really sure about that.<br>
<br>
The VisualWorks team back before Cincom (ie the team that started ParcPlace) were very sure on this point.<br>
<br>
> <br>
> Just my humble oppinion though. :)<br>
> <br>
> Cheers,<br>
> Patrick<br>
> <br>
> <br>
> ________________________________________<br>
> From: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> on behalf of Jakob Reschke <<a href="mailto:jakres%2Bsqueak@gmail.com" target="_blank">jakres+squeak@gmail.com</a>><br>
> Sent: Wednesday, July 13, 2022 10:12:29 AM<br>
> To: The general-purpose Squeak developers list<br>
> Subject: Re: [squeak-dev] String & Text<br>
> <br>
> A common idiom is 'string literal' translated format: {...}<br>
> <br>
> While textual placeholders may make the correct placement of the placeholders in the translated phrase easier, there is also the danger that an inexperienced translator will translate the placeholder's identifier. That would obviously break the intended formatting.<br>
> <br>
> This is independent of the question whether Text and String should both support textual placeholders or not.<br>
> <br>
> <br>
> Am Mi., 13. Juli 2022 um 10:09 Uhr schrieb Jakob Reschke <<a href="mailto:jakres%2Bsqueak@gmail.com" target="_blank">jakres+squeak@gmail.com</a><mailto:<a href="mailto:jakres%252Bsqueak@gmail.com" target="_blank">jakres%2Bsqueak@gmail.com</a>>>:<br>
> Hi,<br>
> <br>
> Maybe it would be better if they did not share so much of the protocol. So that the system guided you better when to use String and when to use Text, separating the responsibilities more.<br>
> <br>
> For example, I would argue that the asText send is misplaced in this example from AbstractFont>>#browseGlyphsByCategoryOf:select:label:<br>
> <br>
> separatorBlock := [:codePoints :category |<br>
> (('\{1}\\' withCRs asText<br>
> format: { Unicode generalCategoryLabels at: category+1 ifAbsent: ['n/a'] })<br>
> addAttribute: (TextFontReference toFont: TextStyle defaultFixedFont);<br>
> addAttribute: (PluggableTextAttribute evalBlock: [self browseGlyphsByCategoryOf: codePoints select: aBlock label: aLabelOrNil]);<br>
> yourself) ].<br>
> <br>
> asText could just as well come after the format:.<br>
> <br>
> Later in the same method comes an example, which is not criticized so easily, where pieces with attributes already applied are inserted via format:<br>
> <br>
> contents := (('Family name: {1}{6}\ Emphasis: {2}\ Point size: {3} ({4}ppi {5}px{7})\' withCRs asText format: { self familyName asText addAttribute: (PluggableTextAttribute evalBlock: [self explore]); yourself. [self emphasisString] on: Error do: [self
subfamilyName]. self pointSize. self pixelsPerInch. self height. isRange ifTrue: [''] ifFalse: [' (selected code points)']. (self isTTCFont and: [(tmp := self extraGlyphScale) ~= 1]) ifFalse: [''] ifTrue: [' ', (tmp * 100) rounded asString, '%'] }) addAttribute:
(TextFontReference toFont: TextStyle defaultFixedFont); yourself).<br>
> <br>
> Many of the occurrences of Text>>format: that I saw are used to insert links in the text template, or highlighted pieces.<br>
> <br>
> So I guess my opening statement is just dreaming without much practical expertise in the concrete matter. Since Text and String are already interchangeable in certain aspects, you cannot simply roll back without breaking lots of things. Under these circumstances
I agree that they should behave equivalently for the protocol that they do share. Otherwise an existing pair of '...' and format: may suddenly fail if you put asText between the two later.<br>
> <br>
> +1 for adding symbolic placeholders to Text >> #format:, unless format: gets removed from Text or the feature gets removed from String again. ;-)<br>
> <br>
> Kind regards,<br>
> Jakob<br>
> <br>
> <br>
> Am Mi., 13. Juli 2022 um 08:48 Uhr schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a><mailto:<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>>:<br>
> Hi all --<br>
> <br>
> What are your thoughts on String and Text. In GUI programming, it<br>
> is rather annoying to have to sprinkle #asText all over the code. It's<br>
> nice to have most important protocol shared between String and Text.<br>
> <br>
> The recent change to only String >> #format: (see Collections-cmm.1016)<br>
> to support symbols as placeholders indicates kind of a disagreement<br>
> in how Text should be used in (GUI) code. Well, if some message is<br>
> not there in Text, it is easy to find out. However, having a protocol there<br>
> with different details feels rather challenging.<br>
> <br>
> I accept that not all protocols are shared between String and Text.<br>
> I do not like inconsistencies of method implementations where the<br>
> message (and signature) is identical.<br>
> <br>
> +1 for adding symbolic placeholders to Text >> #format: as well.<br>
> <br>
> Best,<br>
> Marcel<br>
> <br>
> <br>
<br>
</div>
</span></span>
</div>
<br>
</blockquote></div>
</div></blockquote></div>