<body><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
Note I would rather rename #morphicOpenWith: to #openAsTool or similar because (1) to not confuse with the rather old pattern "morphicOpen..." and "mvcOpen..." and (2) it already is in the scope of Morphic. No need to encode this in the selector, too.<div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 05.10.2017 08:11:58 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:</p><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
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.<div><br></div><div>Just my two cents. :)</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 05.10.2017 04:40:46 schrieb Chris Muller <asqueaker@gmail.com>:</p>#buildWith: is a method for just ToolBuilders. The clarity of the<br>decision of whether to build or not was articulated by the code of the<br>class responsible for it. A dispatch seems unnecessary here. In<br>fact, introducing Morph>>#buildWith: adds yet another muddle-method to<br>its already-large API, and now inherited by the entire hierarchy.<br>Will it invite people to start overriding it in subclasses as an<br>alternative way to use ToolBuilder? Maybe. I think they'll at least<br>be confused about why it's in Morph.<br><br>IMO, this is one of those times when a type check was the simplest and<br>best way to go.<br><br><br>On Mon, Oct 2, 2017 at 7:09 PM, <commits@source.squeak.org> wrote:<br>> tim Rowledge uploaded a new version of ToolBuilder-Morphic to project The Trunk:<br>> http://source.squeak.org/trunk/ToolBuilder-Morphic-tpr.196.mcz<br>><br>> ==================== Summary ====================<br>><br>> Name: ToolBuilder-Morphic-tpr.196<br>> Author: tpr<br>> Time: 2 October 2017, 5:09:16.231117 pm<br>> UUID: 7036c368-757d-4824-ac4a-52ac133665f3<br>> Ancestors: ToolBuilder-Morphic-nice.195<br>><br>> Rather than testing an argument for morphnicity, how about jaust making a morph do the right thing (ie nothing)?<br>><br>> Not entirely clear that the 'problem' can ever really arise, but I can't see any way to prove either case.<br>><br>> =============== Diff against ToolBuilder-Morphic-nice.195 ===============<br>><br>> Item was added:<br>> + ----- Method: Morph>>buildWith: (in category '*ToolBuilder-Morphic-opening') -----<br>> + buildWith: aToolBuilder<br>> + "A Morph is already built, so simply return myself"<br>> + ^self!<br>><br>> Item was changed:<br>> ----- Method: MorphicToolBuilder>>open: (in category 'opening') -----<br>> open: anObject<br>> "Build and open the object. Answer the widget opened."<br>> +<br>> + ^ (self build: anObject) morphicOpenWith: self!<br>> - | morph |<br>> - morph := anObject isMorph ifTrue: [anObject] ifFalse: [self build: anObject].<br>> - ^ morph morphicOpenWith: self!<br>><br>><br><br></commits@source.squeak.org>
</blockquote>
</div>
</blockquote>
</div></body>