[squeak-dev] The Trunk: ToolBuilder-Morphic-tpr.196.mcz
asqueaker at gmail.com
Thu Oct 5 02:39:55 UTC 2017
#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:
> ==================== 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!
More information about the Squeak-dev