Hi Marcel,

> > 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.
>
> It's rather easy. Once we have a CharacterCollection, we can
> finally see the special cases on String. The common stuff can be
> moved up to then benefit both String and Text.

I understand.  CharacterCollection would make it so we "could" do it, but
it's still worth scrutinizing heavily first whether we should.

> > In other words, an incomplete mess for an indefinite period of time.
>
> Disagree. This kind of refactoring does not look too difficult.

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.   :)

> > By removing all the domain stuff [...]
>
> I think that we have a different understand of the term "domain"
> here. Maybe you are worried about Magma. If so, please
> elaborate your concerns from that perspective.

No, I'm speaking strictly in terms of good OO design, where too many
responsibilities for a class is considered not good design.

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.

(Tim wrote:)
> Oh, I'm not wanting to have any tabs or spaces inserted - I want the
formatting to be live and use the left indent.
> Shout does all that work to colour (etc) the text so why not use the fact
that it detects comments.

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!

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.

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..

> > #format: was introduced to Text in 2019.
>
> And long overdue since at least 2015. ;-P Thanks again,
> Christoph (ct) for adding it! It made GUI programming much
> easier. I had that one in mind for many years now.
>...
> > I don't think updates to Text will or should occur except
> > when driven by specific need.

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, *didn't*, in fact, need that
responsibility, if not "doesn't", going forward.

In summary, IMO, if there's any way to keep Text's responsibilities
separate, it's at least worth considering.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220715/02de0a92/attachment.html>