isTextMorph

I have no idea the answer, but it's a curious question.  A quick look
at the api differences vs. similarities and, just by those numbers, it
doesn't look good..   :/

"explore it"
| tm ptm |
tm := TextMorph methodDictionary keys.
ptm := PluggableTextMorph methodDictionary keys.
{  {'TextMorph-specific'. tm difference: ptm. }.
{'PluggableTextMorph-specific'.  ptm difference: tm}.
{'Common'.  ptm intersection: tm.} }




On Sun, Jun 3, 2018 at 1:30 PM, Eliot Miranda <[hidden email]> wrote:

A bigger and more interesting question is why on earth we have three distinct classes. I suspect unfinished experiments that got glommed into the system without adequate thought and left there because nobody knows what the hell was really intended.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Earth is 98% full...please delete anyone you can.

I suspect if you spent half as much time reading the code as
your thesaurus, you may find the answer.   :)

They serve at different layers of abstraction, necessarily.


On Sun, Jun 3, 2018 at 3:30 PM, tim Rowledge <[hidden email]> wrote:
> A bigger and more interesting question is why on earth we have three distinct classes. I suspect unfinished experiments that got glommed into the system without adequate thought and left there because nobody knows what the hell was really intended.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Earth is 98% full...please delete anyone you can.
>
>
>

> On 03-06-2018, at 3:15 PM, Jakob Reschke <[hidden email]> wrote:
>
[snip]

> Regarding PluggableTextMorphPlus and the fact that PluggableTextMorph does not have a class comment, Tim might have a point. The Plus class does have a comment: "A pluggable text morph with support for color." But since any (Pluggable)TextMorph also supports colored text somehow, this explanation is a little too brief. It adds support for accessing the color from the model and adds the optional text styler for syntax highlighting. ...and an acceptAction, but this is definitely not captured in the class comment.

The comment is definitely inadequate since that class adds stuff that seems to be to support Shout styling and also adds another layer of accept related action customisation. An important basic tool related class like PluggableTextMorph having no comment that gives us a decent description of what it is for is not helpful. I suspect that the two could be merged to good effect.
>
> Anyway, PluggableTextMorph*Plus* is what MorphicToolBuilder builds when you ask for a pluggable text, be it for code or plain text.

Exactly - so is there real value in the non-Plus class?

TextMorph is interesting because amongst other things it is (well the TextMorphForEditView subclass) wrapped into a PluggableTextMorphPlus. It does have a comment, which is nice (special pun hidden in there).  Wrapping a 'single minded' morph to  make a pluggable one can be useful but you also get stuck with having to forward a load of messages and remembering that you are wrapping a class that can change. We have to hope that everyone that ever changes the wrapped class remembers to update the wrapper to keep things working.  I suggest that it is easier on everyone if the 'root' class is pluggable and has defaults for the pluggable parts that make it easy to use as a single minded object.

I'm fairly sure that things could be drastically simplified. Simpler is easier to document and easier to maintain and easier to improve. Simpler is very often better.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Base 8 is just like base 10, if you are missing two fingers.