On Sun, 13 Aug 2006 18:31:23 +0200, Damien Cassou wrote:
Yes. And, into the other direction, even in good core methods one often
finds things like
^ dict at: aKey ifAbsent: [nil]
There seems to be a "natural" confusion between "object" value and
block "value".
What's the problem with that ?
The lack of understanding the expressive power of the software developer
is the problem. Why always use a hammer? Because everything looks like
nails?
Yes, 'nil value' answers nil but 'nil' is not a block and #at:ifAbsent:
waits for a block (the parameter is called aBlock).
No, #at:ifAbsent: doesn't wait for an instance of BlockContext. Smalltalk
is typeless and, if at all, only has *one* (the universal) type.
It is shorter to write 'nil' directly I agree.
And the compiler is not forced to emit code for a BlockContext and the VM
is not forced to create a BlockContext only for throwing it away unused
(unused in the sense that nil == [nil] value). It is like writing (x)
versus (0+x) or (1*x).
What is more problematic in my point of view is code like this:
AbstractLauncher>>parameterAt: parName ifAbsent: aBlock
"Return the parameter named parName.
Evaluate the block if parameter does not exist."
^self parameters
at: parName asUppercase
ifAbsent: [aBlock value]
It may be me (still a beginner), but it looks equivalent to
^self parameters
at: parName asUppercase
ifAbsent: aBlock
Yes, anObject == [anObject] value.
which is faster and clearer in my opinion.
Sure.
/Klaus
_______________________________________________
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
