People will think #buildWith: is a hook method, are you saying it is
now?  I don't think you are, but as it was even put into the
'ToolBuilder-Morphic-opening' category, people will think it is (!), and I
can see that being incredibly confusing for them trying to understand
how the system is intended to be programmed.

This shifting of the responsibility for "building" from the
ToolBuilder to Morph's requires a great more consideration than
"betcha can't prove I broke it...."    This was an emotional reaction
to a type-check, not a refactoring.  What about sending the right
clues to people reading the code?  What about proper delegation of
responsibility?  What about good API design?

Please don't take this personally Tim, but it tends to be better to
take your frustrations with the code to your peers on the list first
(as you sometimes do, thank you) than publish these same-day,
reactionary commits.


On Thu, Oct 5, 2017 at 1:11 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> Well, since Tobias started this refactoring in April 2017 to clear-up
> MorphicToolBuilder >> #open, this seems a logical next step to also have a
> #buildWith: in Morph.
>
> Just my two cents. :)
>
> Best,
> Marcel
>
> Am 05.10.2017 04:40:46 schrieb Chris Muller <asqueaker at gmail.com>:
>
> #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, 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!
>>
>>
>
>
>
>