<div dir="ltr">I scrolled through the protocols of String and Text two days ago. The main categories of methods (which don't overlap well with the classification in the image) on String that I remember are:<div>- general string parts enumeration (finding, lines)</div><div>- general string manipulation (trimming, splitting, slicing, character substitution, substring substitution, case changes, padding, ...)</div><div>- tokenization and parsing (e. g. csv/tsv), some of it Smalltalk language-specific (getters, setters, arguments/keywords count)</div><div>   - natural language conversions (e. g. camelCase <-> words)</div><div>   - MIME</div>- formatting (interpolation, line wrapping or joining, indentation)<div><div>- collation and (equality) comparison</div><div>- pattern matching</div><div>- similarity computations</div><div>- character classification (digits, letters, whitespace, ...)</div><div>- graphics display<br><div>- arithmetic with numbers</div><div>- multilingual stuff (among others: dealing with leadingChar)</div><div>- character set conversions<br></div><div>- VM paths <-> Squeak paths conversion</div><div>- HTML and HTTP conversions (e. g. URL %-decoding)<br></div><div>- crc16</div><div>- extension methods from various packages like Etoys, JSON, Monticello, Morphic, Regex, Network, ...</div><div>   - chronology conversions</div><div><br></div><div>Next to "format:" there seems to be yet another interpolation mechanism in "expandMacrosWithArguments:".</div><div><br></div><div>Overall, some methods treat strings as text, others treat them as technical data (markup, file paths, URLs, encoding---ByteArrays with characters). The leadingChar stuff is strangely in the middle of the two. Text functionality like interpolation can also be used to produce technical data, of course.</div><div><br></div><div>Which selectors Text also understands is at times chaotic. Of some groups of related selectors, Text may just understand one of them. When it comes to Text's "core domain" of displaying, it does not understand any of the displayAt:/displayOn:* selectors...</div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 16. Juli 2022 um 03:28 Uhr schrieb Chris Muller <<a href="mailto:ma.chris.m@gmail.com">ma.chris.m@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Marcel,<br><br>> > But until we do that, and whole hog like Eliot suggested,<br>> > what we will have are *some* domain things that String<br>> > can do that Text can't -- a partial overlap.<br>><br>> It's rather easy. Once we have a CharacterCollection, we can<br>> finally see the special cases on String. The common stuff can be<br>> moved up to then benefit both String and Text.<br><br>I understand.  CharacterCollection would make it so we "could" do it, but it's still worth scrutinizing heavily first whether we should.<br><br>> > In other words, an incomplete mess for an indefinite period of time.<br>><br>> Disagree. This kind of refactoring does not look too difficult.<br><br>I was speaking about the state of the system until such time as that refactoring was completed, which is indefinite.  Until then, the API would be, by definition, incomplete.  We can disagree about it being a "mess", though.   :)<br><br>> > By removing all the domain stuff [...]<br>><br>> I think that we have a different understand of the term "domain"<br>> here. Maybe you are worried about Magma. If so, please<br>> elaborate your concerns from that perspective.<br><br>No, I'm speaking strictly in terms of good OO design, where too many responsibilities for a class is considered not good design.<div><br></div><div>In the other thread, Tim just wrote this about formatting comments.  It stuck out to me as an example relevant to the question of this thread.<div><br></div><div>(Tim wrote:)<br>> Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. <div>> Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.</div><div><br></div><div>I agree with him 100%, and this continues to remind us of the numerous responsibilities that can be considered "presentation" only.  Before I had only mentioned fonts, colors, and attributes (bold, italic, center, right justify, left jusify, etc.), but Tim reminds us that indentation and layout is in there, too!</div><div><br></div><div>This is already a nice collection of behaviors that completely distinct from the ones concerned with the _contents_ of the Text (e.g., its 'string'), which is what I mean when I refer to the "domain" vs. presentation responsibilities of Text.</div><div><br></div><div>Maybe bloating up Text with such a huge API (domain + presentation) MIGHT be the best way out.  I don't know for sure, and I trust this brilliant community will come down on the right choice.  I'm only saying that some of the usual OO design quality metrics (e.g., number of methods per class, among others) will get blown out of the water by this, and that this is a sign that it's really worth being cautious.  It also looks to be a one-way ticket -- eliminating this delineation of responsibility and piling on hundreds of domain accessing / mutating methods onto Text's API will be a lot easier than going the other way.  Once we have 5 years of accumulated dependency on its domain-accessing responsibilities, it would be a lot harder to untangle that in 2027 (in case it became unmanageable) than it was to mash them together in 2022.  I'm not necessarily against mashing them, I just think we should give it some heavy scrutiny first..</div><div><br>> > #format: was introduced to Text in 2019.<br>><br>> And long overdue since at least 2015. ;-P Thanks again,<br>> Christoph (ct) for adding it! It made GUI programming much<br>> easier. I had that one in mind for many years now.</div><div>>...</div><div><div><div><div>> > I don't think updates to Text will or should occur except<br>> > when driven by specific need.</div></div></div></div><div><br></div><div>Christoph chose to add that one, #format:, and not hundreds of others that day.  His decision was based on _something_ which could be considered akin to a "need".  Maybe the lack of need until that "overdue" time expresses that Text, in the least, <i>didn't</i>, in fact, need that responsibility, if not "doesn't", going forward.</div><div><br></div><div>In summary, IMO, if there's any way to keep Text's responsibilities separate, it's at least worth considering.</div><div><br></div></div></div><div> - Chris</div><div><br></div></div>
<br>
</blockquote></div>