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

[John O'Keefe]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openskills.org/pipermail/ansi-smalltalk/attachments/20080904/58a29f80/attachment.htm