<div dir="ltr"><div>I think the 'where do you stop' question is easily answered. You stop when you can't achieve agreement. </div>
<div> </div>
<div>I think we are quite close to agreement in ifNil: and ifNotNil: and far from agreement on other if.. and ifNot... constructs. Further, ifNotNil: with a monadic block as its argument does provide a unique 'convenience' function that has been discussed previously. </div>
<div> </div>
<div>I can see similar value in a whileNotNil: message (with a monadic block), but I think added this construct likely falls on the far side of the 'where do you stop' line -- at least right now.</div>
<div> </div>
<div>I also agree that is... (as in isEmpty) should be the standard pattern for messages that answer a boolean while if... (as in ifNil: []) should be the standard pattern for messaged that evaluate a block based on a boolean.</div>
<div><br clear="all">John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.<br><br><br></div>
<div class="gmail_quote">On Wed, Sep 3, 2008 at 9:57 PM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>"Jim" ( jas at <a href="http://cruzio.com/" target="_blank">cruzio.com</a> ) wrote that he preferred<br>
<br>isNil: a0block<br>notNil: a0block<br>nonNil: a1block<br>and various combinations of those to the by now traditional<br>[ifNil:][ifNotNil:]<br><br>As a Smalltalk user, it's quite important to me that methods<br>taking a block that might or might not be evaluated have<br>
"if" in the keyword selector for that block.<br><br>For example, it's<br> aCollection at: someKey ifAbsent: exceptionBlock<br> ^^<br>ifAbsent:, not isAbsent:, notPresent:, nonPresent:, or<br>
anything else.<br><br>There seem to be three reasons for leaving [ifNil:][ifNotNil:]<br>out:<br>(1) No agreement about the optional argument in the not-nil<br> block; of course the standard could cover just the no-<br> argument case.<br>
(2) These methods aren't really necessary unless you have<br> redefined what nil == ... does. A compiler can turn<br> nil == (expr) ifTrue: b1 ifFalse: b2<br> into whatever<br> (expr) ifNil: b1 ifNotNil: b2<br>
does.<br>(3) Where do you stop? Once you have these, why not<br> b1 while[Not]Nil[: b2]? Why not ifEmpty:ifNotEmpty:?<br> This is actually a serious question; I've wanted<br> b1 whileNotNil: b2 often enough.<br>
<br>On the other hand, the feature is widely available, and is<br>quite intention-revealing, so the answer to (3) is "because<br>these methods _are_ common practice and those aren't."<br>--<br>If stupidity were a crime, who'd 'scape hanging?<br>
<br><br><br><br><br><br><br><br>_______________________________________________<br>ANSI-Smalltalk mailing list<br><a href="mailto:ANSI-Smalltalk@lists.openskills.org" target="_blank">ANSI-Smalltalk@lists.openskills.org</a><br>
<a href="http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk" target="_blank">http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk</a><br></blockquote></div><br></div>