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

[Steve Wart]

Just having refactored several hundred incidents of (expression evaluating
to something) ifNotNil: [:something | ... ] into ifNotNilDo: [ :something |
] I think the saving of the temp var is the only gain.

But it is useful to have that keyword for many people, not all of whom
necessarily share your hesitance in using parentheses :)

Now if certain compilers didn't inline ifNotNil: I could have made the block
argument optional, at least for our application (thank goodness for
extensions).

The horse seems to have left the barn, but if I knew yesterday I was going
to be facing this problem I would have argued for a more elegant solution.
Now it's just another example of the divergent thinking and stubbornness
that keeps code from being easily moved from one Smalltalk implementation to
another.

Speaking of which, namespaces are still a problem.

On Thu, Sep 25, 2008 at 2:35 AM, Andres Valloud <andres.valloud at gmail.com>wrote:

> I am just wondering now... let's say one writes something like this:
>
> something ifNilDo: [:nilObject | nilObject doWhatever]
>
> This does not seem to make a lot of sense because if ifNilDo:
> evaluates the block, then the argument is known to be nil.  So let's
> look at this one
>
> something ifNotNilDo: [:someObject | someObject doWhatever]
>
> Why is this actually useful?  I am not saying it's not, but I am
> having trouble seeing the reason.  Since the receiver is known at this
> time, then I'd be tempted to do something like this:
>
> something ifNotNilDo: [something doWhatever]
>
> and skip the block argument.  One could say "ah but then this requires
> a temp var".  However, expressions such as
>
> something blah ifNotNilDo: [:something | something doWhatever]
>
> are only possible to write without parentheses when "something blah"
> does not have keyword messages in it... which is something that I try
> to avoid as much as possible...
>
> Is this the only gain?
>
> Andres.
>
>
> On Mon, Sep 8, 2008 at 11:50 AM, Paolo Bonzini <bonzini at gnu.org> wrote:
> >
> >>>     ifNotEmptyDo: aBlock
> >>>         ^self isEmpty ifTrue: [aBlock value: self]
> >>
> >> That is still bizarre, if you ask me...
> >
> > Uhm, indeed.  Paste-o or bug!?
> >
> >>> It certainly doesn't involve any sending of the message #do:.
> >>
> >> No. I think Paolo meant that he would read it like that.
> >> It would feel to him as if a #do: iteration was implied.
> >> (I suspect this is what Paolo meant).
> >
> > Yes, thanks for helping decyphering my messages. :-)
> >
> > Paolo
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openskills.org/pipermail/ansi-smalltalk/attachments/20080925/e1797f44/attachment.html