doIfNotNil: -- let's bake the other half
Andrew P. Black
black at cse.ogi.edu
Tue Oct 17 03:24:25 UTC 2000
>From: Lex Spoon [mailto:lex at cc.gatech.edu]
>>The #in: family actually sounds pretty good to me. (I hadn't realized
>>#in: was in the system; I do like the idea!). I like #inIfNotNil:
> >better than #ifNotNilIn:, though -- the first sounds more gramatical.
I think that I prefer IfNotNilDo: or IfNotNilIn: versions better
than "IfNotNilBeValueFor", for the reasons already expressed: that we
don't want to draw attention to the block itself, but instead to its
action, or its value.
By analogy with monadic functional programming, do: emphasizes the
action, and in: the value. In Squeak, they are indistinguishable.
So I vote for either.
I sort of agree that do: has an accepted Smalltalk-specific meaning
of expecting a unary block that will be repeatedly applied to
arguments emitted by the receiver. But, how many times is
"repeatedly"? It depends on the values that one can get out of the
receiver; it might be 100, it might be zero, and yes, it just might
be one. In this case, it happens to be one.
While we are beating on this, I'm going to object to the implementation of in:
in: aBlock
"Evaluate the given block with the receiver as its argument."
(aBlock isKindOf: BlockContext) ifFalse: [self error:
'expecting a block'].
^ aBlock value: self
Do you agree that the class test leaves a bad smell? If a test is
needed to warn the unwary that points, say are not good arguments,
then (IMnotsoHO) the "right" condition is:
(aBlock repondsTo: #value:)
because that is the correct precondition for the next statement. (I
can easily make objects that respond to value: that are not
subclasses of BlockContext.) Indeed, I sometimes write tests like
that, for example when writing methods that take blocks as arguments
and then store them away for later use. My justification is that I
would rather that an inappropriate argument is detected sooner than
later.
However, in this case, the inappropriate argument will be detected
immediately, on execution of the very next statement. So why bother
wasting those 4 microseconds ... we may need them someday :-)
Andrew
More information about the Squeak-dev
mailing list
|