#buildWith: is a method for just ToolBuilders.  The clarity of the
decision of whether to build or not was articulated by the code of the
class responsible for it.  A dispatch seems unnecessary here.  In
fact, introducing Morph>>#buildWith: adds yet another muddle-method to
its already-large API, and now inherited by the entire hierarchy.
Will it invite people to start overriding it in subclasses as an
alternative way to use ToolBuilder?  Maybe.  I think they'll at least
be confused about why it's in Morph.

IMO, this is one of those times when a type check was the simplest and
best way to go.


On Mon, Oct 2, 2017 at 7:09 PM,  <commits at source.squeak.org> wrote:
> tim Rowledge uploaded a new version of ToolBuilder-Morphic to project The Trunk:
> http://source.squeak.org/trunk/ToolBuilder-Morphic-tpr.196.mcz
>
> ==================== Summary ====================
>
> Name: ToolBuilder-Morphic-tpr.196
> Author: tpr
> Time: 2 October 2017, 5:09:16.231117 pm
> UUID: 7036c368-757d-4824-ac4a-52ac133665f3
> Ancestors: ToolBuilder-Morphic-nice.195
>
> Rather than testing an argument for morphnicity, how about jaust making a morph do the right thing (ie nothing)?
>
> Not entirely clear that the 'problem' can ever really arise, but I can't see any way to prove either case.
>
> =============== Diff against ToolBuilder-Morphic-nice.195 ===============
>
> Item was added:
> + ----- Method: Morph>>buildWith: (in category '*ToolBuilder-Morphic-opening') -----
> + buildWith: aToolBuilder
> +       "A Morph is already built, so simply return myself"
> +       ^self!
>
> Item was changed:
>   ----- Method: MorphicToolBuilder>>open: (in category 'opening') -----
>   open: anObject
>         "Build and open the object. Answer the widget opened."
> +
> +       ^ (self build: anObject) morphicOpenWith: self!
> -       | morph |
> -       morph := anObject isMorph ifTrue: [anObject] ifFalse: [self build: anObject].
> -       ^ morph morphicOpenWith: self!
>
>