[ANSI-Smalltalk] Re: A list of interesting methods, ifNotNil:

[Andres Valloud]

Note, however, that while

  true ifFalse: [5]

evaluates to nil,

  5 ifNil: [7]

evaluates to 5.  I thought I'd point this out because ifNil: does not
behave like ifTrue:.

Andres.


On Thu, Sep 4, 2008 at 3:04 AM, John O'Keefe
<wembley.instantiations at gmail.com> wrote:
> I think the 'where do you stop' question is easily answered.  You stop when
> you can't achieve agreement.
>
> 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.
>
> 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.
>
> 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.
> John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.
>
>
> On Wed, Sep 3, 2008 at 9:57 PM, Richard A. O'Keefe <ok at cs.otago.ac.nz>
> wrote:
>>
>> "Jim" ( jas at cruzio.com ) wrote that he preferred
>>
>> isNil: a0block
>> notNil: a0block
>> nonNil: a1block
>> and various combinations of those to the by now traditional
>> [ifNil:][ifNotNil:]
>>
>> As a Smalltalk user, it's quite important to me that methods
>> taking a block that might or might not be evaluated have
>> "if" in the keyword selector for that block.
>>
>> For example, it's
>>   aCollection at: someKey ifAbsent: exceptionBlock
>>                           ^^
>> ifAbsent:, not isAbsent:, notPresent:, nonPresent:, or
>> anything else.
>>
>> There seem to be three reasons for leaving [ifNil:][ifNotNil:]
>> out:
>> (1) No agreement about the optional argument in the not-nil
>>   block; of course the standard could cover just the no-
>>   argument case.
>> (2) These methods aren't really necessary unless you have
>>   redefined what nil == ... does.  A compiler can turn
>>        nil == (expr) ifTrue: b1 ifFalse: b2
>>   into whatever
>>       (expr) ifNil: b1 ifNotNil: b2
>>   does.
>> (3) Where do you stop?  Once you have these, why not
>>   b1 while[Not]Nil[: b2]?  Why not ifEmpty:ifNotEmpty:?
>>   This is actually a serious question; I've wanted
>>   b1 whileNotNil: b2 often enough.
>>
>> On the other hand, the feature is widely available, and is
>> quite intention-revealing, so the answer to (3) is "because
>> these methods _are_ common practice and those aren't."
>> --
>> If stupidity were a crime, who'd 'scape hanging?
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> ANSI-Smalltalk mailing list
>> ANSI-Smalltalk at lists.openskills.org
>> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>