<br><font size=2 face="sans-serif">Benoit St-Jean wrote:</font>
<br><font size=2 face="sans-serif"> >>For instance why would you write:</font>
<br>
<br><font size=2 face="sans-serif"> >>anObject isFoo</font>
<br><font size=2 face="sans-serif"> >> ifTrue: [^#foo]</font>
<br><font size=2 face="sans-serif"> >> ifFalse: [^#bar]</font>
<br>
<br><font size=2 face="sans-serif"> >>instead of:</font>
<br>
<br><font size=2 face="sans-serif"> >>^anObject isFoo</font>
<br><font size=2 face="sans-serif"> >> ifTrue: [#foo]</font>
<br><font size=2 face="sans-serif"> >> ifFalse: [#bar]</font>
<br>
<br><font size=2 face="sans-serif"> >>I always thought that clean blocks was the way to go and</font>
<br><font size=2 face="sans-serif"> >>that you should always try to avoid returning from</font>
<br><font size=2 face="sans-serif"> >>inside a block when possible, so what's the deal here?</font>
<br>
<br><font size=2 face="sans-serif">Yes, I think a block without a return is the better solution,</font>
<br><font size=2 face="sans-serif">BUT: <b>ifTrue:ifFalse: </b>is inlined, and I think the blocks are</font>
<br><font size=2 face="sans-serif">removed due to inlining. So the difference does not matter here.</font>
<br>
<br><font size=2 face="sans-serif">Nevertheless, the use of return is a question of style and I prefer</font>
<br><font size=2 face="sans-serif"> ^anObject isFoo</font>
<br><font size=2 face="sans-serif"> ifTrue: []</font>
<br><font size=2 face="sans-serif"> ifFalse: []</font>
<br><font size=2 face="sans-serif">This form clearly states the fact that we will return,</font>
<br><font size=2 face="sans-serif">while</font>
<br><font size=2 face="sans-serif"> anObject isFoo</font>
<br><font size=2 face="sans-serif"> ifTrue: [ <...> ^#foo]</font>
<br><font size=2 face="sans-serif"> ifFalse: [<...> ^#bar]</font>
<br><font size=2 face="sans-serif">hides this fact. </font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">To the best of my understanding, there is only one</font>
<br><font size=2 face="sans-serif">situation that requires a return within a block:</font>
<br>
<br><font size=2 face="sans-serif"> foo</font>
<br><font size=2 face="sans-serif"> self doSomethingOnFailure: [^false].</font>
<br><font size=2 face="sans-serif"> self doSomthingElse.</font>
<br><font size=2 face="sans-serif"> ^true</font>
<br>
<br><font size=2 face="sans-serif"> doSomethingOnFailue: failureBlock</font>
<br><font size=2 face="sans-serif"> <...></font>
<br><font size=2 face="sans-serif"> failureBlock value</font>
<br><font size=2 face="sans-serif"> <...></font>
<br>
<br><font size=2 face="sans-serif">This is essentially a nonlocal jump: The evaluation of</font>
<br><font size=2 face="sans-serif">"failureBlock value" causes the method <b>foo</b> to be left</font>
<br><font size=2 face="sans-serif">with result value false. That is, from doSomethinOnFailue:</font>
<br><font size=2 face="sans-serif">we jump back to the place where foo was called. </font>
<br>
<br>
<br><font size=2 face="sans-serif"> >>BTW, if you look at senders of ifTrue:ifFalse: (or</font>
<br><font size=2 face="sans-serif"> >>vice-versa) you only get a few methods... Is it</font>
<br><font size=2 face="sans-serif"> >>broken or that is the normal "behavior" since that</font>
<br><font size=2 face="sans-serif"> >>"message" is inlined and not reaaly a message send?</font>
<br>
<br>
<br><font size=2 face="sans-serif">Yes, inlined methods can not found by "senders of... ".</font>
<br><font size=2 face="sans-serif">"senders of ... " scans compiled methods for attached</font>
<br><font size=2 face="sans-serif">message symbols, and for an inlined message no</font>
<br><font size=2 face="sans-serif">message symbol is attached.</font>
<br>
<br><font size=2 face="sans-serif">It is sometimes asked whether methods that are inlined</font>
<br><font size=2 face="sans-serif">by the compiler are needed in the image at all. They</font>
<br><font size=2 face="sans-serif">are needed because they can be sent with a perform.</font>
<br>
<br><font size=2 face="sans-serif">Try this (in some class): </font>
<br>
<br><font size=2 face="sans-serif">test</font>
<br>
<br><font size=2 face="sans-serif"> | string idx |</font>
<br>
<br><font size=2 face="sans-serif"> string := 'hello>>Benoit'.</font>
<br><font size=2 face="sans-serif"> idx := 1.</font>
<br><font size=2 face="sans-serif"> [(string at: idx) = $>]</font>
<br><font size=2 face="sans-serif"> perform: #whileFalse: with: [idx := idx + 1]. </font>
<br><font size=2 face="sans-serif"> ^string copyFrom: idx to: string size. </font>
<br>
<br><font size=2 face="sans-serif">This method will be found as a sender of #whileFalse:.</font>
<br>
<br><font size=2 face="sans-serif">When you insert a "self halt." in BlockContext>>whileFalse:</font>
<br><font size=2 face="sans-serif">and execute the method, the debugger will stop at the halt. </font>
<br>
<br><font size=2 face="sans-serif">The following example is a bit tricky: </font>
<br>
<br><font size=2 face="sans-serif"> | string idx |</font>
<br>
<br><font size=2 face="sans-serif"> string := 'hello>>Benoit'.</font>
<br><font size=2 face="sans-serif"> idx := 1.</font>
<br><font size=2 face="sans-serif"> [(string at: idx) = $>]</font>
<br><font size=2 face="sans-serif"> whileFalse: [idx := idx + 1]; " NOT inlined "</font>
<br><font size=2 face="sans-serif"> whileTrue: [idx := idx + 1]. " inlined "</font>
<br><font size=2 face="sans-serif"> string copyFrom: idx to: string size.</font>
<br>
<br><font size=2 face="sans-serif">Squeak 3.2 does not accept this as valid code (<b>why ??</b>), some</font>
<br><font size=2 face="sans-serif">other Smalltalks do. Those who do (Visual Works and IBM Smalltalk),</font>
<br><font size=2 face="sans-serif">create a message send instruction for the first block (that is,</font>
<br><font size=2 face="sans-serif">the method BlockContext>>whileFalse: will be executed) and</font>
<br><font size=2 face="sans-serif">inlined code for the second block (the method Blockcontext>>whileTrue:</font>
<br><font size=2 face="sans-serif">will not be executed). The well-known Digitalk Smalltalk V/286 crashed </font>
<br><font size=2 face="sans-serif">with a general protection fault, but that was a compiler bug that could</font>
<br><font size=2 face="sans-serif">be fixed after decompilation of the compiler.</font>
<br>
<br><font size=2 face="sans-serif">Bye</font>
<br>
<br><font size=2 face="sans-serif">Boris <br>
<br>
msg systems ag<br>
Fraunhoferstraße 9<br>
85737 Ismaning<br>
<br>
Tel.: (+89) 96 101 546<br>
mailto: Boris_Gaertner@msg.de</font>