<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>> <span style="font-size:12pt">There is no syntax for blockReturn because it wouldn't be possible to use it.</span></p>
<div><br>
</div>
<p></p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</font></div>
</div>
</div>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">What do you mean? Here is an ugly but working example of "continue" in Smalltalk - provided that the block is not inlined:</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div>(1 to: 10) do: [:i |</div>
<div><span style="white-space:pre"></span>| j |</div>
<div><span style="white-space:pre"></span>i even ifFalse: [thisContext return].</div>
<div><span style="white-space:pre"></span>j := i squared.</div>
<div><span style="white-space:pre"></span>Transcript showln: i squared].</div>
<br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">However, I agree that you should never use this in practice, it's too confusing. ;-)</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">Best,</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">Christoph</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves@caesar.elte.hu><br>
<b>Gesendet:</b> Montag, 30. März 2020 23:04:18<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] #doWhileTrue: (was: The Trunk: System-nice.1149.mcz)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Christoph,<br>
<br>
On Mon, 30 Mar 2020, Thiede, Christoph wrote:<br>
<br>
> <br>
> Hi Nicolas,<br>
> <br>
> <br>
> I don't see your point of #doWhileTrue: being not idiomatic. What exactly do you mean by that except for "unfamiliar"?<br>
> <br>
> <br>
> However, I agree that the names are confusing, compared to #whileTrue: etc.<br>
> <br>
> +1 for naming them #repeatWhile: and #repeatUntil: instead!<br>
> <br>
> <br>
> > But that still means that we have two ways to express exactly the same thing, which by first principle should not be<br>
> <br>
> > (economy of implementation, of tests, of documentation, etc... small is beautiful !).<br>
> <br>
> Well, that's another a question of semantics, again. :) Remember my examples about #ifNotNil:/#==> etc.? Convenience methods support ease of writing and reading.<br>
> <br>
> > Really, not kidding?<br>
> The example is taken from BookMorph >> #saveOnUrlPage:. I did not read it in context, too ^^<br>
> <br>
> > Is the following better? > <br>
> > [newPlace := self getNewPlace.<br>
> > file:= ServerFile new fullPath: newPlace.<br>
> > file exists] whileTrue<br>
> <br>
> In my opinion, #repeatUntil: would still be better :)<br>
> <br>
> > Note that I did not add non local block return in the middle of the block... > It was in the original method, doWhileTrue did not solve it.<br>
> <br>
> I was referring to blockReturn in the bytecode sense. Here is another example of confusing blockReturns:<br>
> <br>
> (foo satisfiesSomeCondition or: [|baz|<br>
> baz := bar asBaz.<br>
> foo cacheDuring: [<br>
> baz satisfiesSomeOtherCondition]])<br>
> ifTrue: [...]<br>
> <br>
> Hard to follow the control flow, isn't it? If I have the choice, I avoid these statements and use blocks,<br>
<br>
Whether or not the above example is okay or not depends on what [...] is. <br>
For example, if it's simply ^self, then the use of #or: is unnecessary and <br>
the computation which reduces legibility can be moved out to the main flow <br>
of the method.<br>
<br>
> either) to pass a piece of code to another object and compose control flows,<br>
> or) to explicitly pass a value to be evaluated lazily.<br>
> Both at once can be confusing. I think there is a good reason why there is no syntax for blockReturn like we have one for methodReturn (^).<br>
<br>
There is no syntax for blockReturn because it wouldn't be possible to use it.<br>
<br>
<br>
Levente<br>
<br>
> <br>
> Best,<br>
> Christoph<br>
> <br>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com><br>
> Gesendet: Montag, 30. März 2020 20:56:43<br>
> An: The general-purpose Squeak developers list<br>
> Betreff: Re: [squeak-dev] #doWhileTrue: (was: The Trunk: System-nice.1149.mcz) <br>
> <br>
> <br>
> Le lun. 30 mars 2020 à 19:58, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> a écrit :<br>
><br>
> Hi Nicolas,<br>
> <br>
><br>
> > There is no other sender of doWhileFalse: doWhileTrue: and my advice would be to deprecate them. YAGNI.<br>
> <br>
> <br>
> So my image actually contains around two dozen senders of #doWhileTrue: and #doWhileFalse: (Squot, Pheno and some of my own code). As mentioned somewhere else in the past, I actually like them and find them very useful.<br>
> <br>
> In my opinion, many senders of #whileTrue and #whileFalse should be refactored to use #doWhileTrue:/#doWhileFalse:. Here is a random example:<br>
> <br>
> [newPlace := self getNewPlace.<br>
> dir := ServerFile new fullPath: newPlace.<br>
> (dir includesKey: dir fileName)] whileTrue.<br>
> <br>
> I find that's ugly and counter-intuitive! I would rewrite this in the following way:<br>
> <br>
> [newPlace := self getNewPlace.<br>
> dir := ServerFile new fullPath: newPlace]<br>
> doWhileTrue: [dir includesKey: dir fileName].<br>
> <br>
> <br>
> The first thing that upsets me is that they are not idiomatic. #whileTrue: and in a lesser way #whileTrue are.<br>
> The second thing that upsets me is that the names are REALLY too close to #whileTrue:<br>
> So at first, I was confused by the fact that they looked like synonyms.<br>
> Then I wondered exactly the same, what the hell has to be true?<br>
> Especially when the sole sender in trunk is [] doWhileTrue: true ;)<br>
> <br>
> IMO, they might be better spelled #repeatWhile: and #repeatUntil:<br>
> But that still means that we have two ways to express exactly the same thing, which by first principle should not be<br>
> (economy of implementation, of tests, of documentation, etc... small is beautiful !).<br>
> <br>
> We might discuss which is more readable, maybe<br>
> <br>
> [newPlace := self getNewPlace.<br>
> dir := ServerFile new fullPath: newPlace]<br>
> repeatWhile: [dir includesKey: dir fileName].<br>
> <br>
> is more revealing than:<br>
> <br>
> [newPlace := self getNewPlace.<br>
> dir := ServerFile new fullPath: newPlace.<br>
> (dir includesKey: dir fileName)] whileTrue.<br>
> <br>
> IMO, it's a biased example, because the whole snippet is un-comprehensible.<br>
> So a ServerFile behaves like a ServerDirectory (from which it inherits...), oh nice (???).<br>
> And a ServerFile which would includes some item with same name as itself would mean that the file already exists...<br>
> Really, not kidding?<br>
> <br>
> So IMO that's what makes the snippet illegible, not whileTrue.<br>
> Is the following better?<br>
> <br>
> [newPlace := self getNewPlace.<br>
> file:= ServerFile new fullPath: newPlace.<br>
> file exists] whileTrue<br>
> <br>
> Anyway, the second one is there for such a long time that you can't expunge it that easily. It's idiomatic...<br>
> <br>
> The latter just reads easier. blockReturns in multi-statement blocks are not really intuitive.<br>
> <br>
> <br>
> Note that I did not add non local block return in the middle of the block...<br>
> It was in the original method, doWhileTrue did not solve it.<br>
><br>
> In the first version, when scanning the method quickly, I read "okay, something with places and directories is done, while true ...," I wonder "what has to be true?" and have to look back to the end of the block<br>
> and find the beginning of the last statement.<br>
> But in the second version, I read "okay, something with places and directories is done, while that directory matches this specific condition." This version directly draws my attention to the important condition.<br>
> <br>
> Happy to hear your counterarguments :-)<br>
> <br>
> Best,<br>
> Christoph<br>
> <br>
> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von commits@source.squeak.org <commits@source.squeak.org><br>
> Gesendet: Montag, 30. März 2020 12:51 Uhr<br>
> An: squeak-dev@lists.squeakfoundation.org; packages@lists.squeakfoundation.org<br>
> Betreff: [squeak-dev] The Trunk: System-nice.1149.mcz <br>
> Nicolas Cellier uploaded a new version of System to project The Trunk:<br>
> <a href="http://source.squeak.org/trunk/System-nice.1149.mcz">http://source.squeak.org/trunk/System-nice.1149.mcz</a><br>
> <br>
> ==================== Summary ====================<br>
> <br>
> Name: System-nice.1149<br>
> Author: nice<br>
> Time: 30 March 2020, 12:50:26.196366 pm<br>
> UUID: ece53b0b-24d2-4d4b-bc91-6794a661f886<br>
> Ancestors: System-ul.1148<br>
> <br>
> avoid neuron storming [...] doWhileTrue: true, it just means [...] repeat<br>
> <br>
> There is no other sender of doWhileFalse: doWhileTrue: and my advice would be to deprecate them. YAGNI.<br>
> <br>
> =============== Diff against System-ul.1148 ===============<br>
> <br>
> Item was changed:<br>
> ----- Method: MOFile>>searchByHash: (in category 'experimental') -----<br>
> searchByHash: aString<br>
> | hashValue nstr index incr key |<br>
> hashValue := self hashPjw: aString.<br>
> incr := 1 + (hashValue \\ (hashTableSize -2)).<br>
> index := (hashValue \\ hashTableSize) .<br>
> [ nstr := (hashTable at: index +1 ).<br>
> nstr = 0 ifTrue: [^nil].<br>
> key := self originalString: nstr.<br>
> key = aString ifTrue: [^self translatedString: nstr].<br>
> index >= (hashTableSize - incr)<br>
> ifTrue: [index := index - (hashTableSize - incr) ]<br>
> ifFalse:[index := index + incr]. <br>
> + ] repeat!<br>
> - ] doWhileTrue: true.!<br>
> <br>
> <br>
> <br>
> <br>
></div>
</span></font>
</body>
</html>