useful discovery: anObject in: aBlock
So, I was lamenting the other day that #do: on a non-collection didn't just iterate over the single item. Of course, that might have been a bit too much DWIM, but in Perl, I frequently would "alias" a complex value for a series of steps, as in:
for my $thing (some complex expression yielding a specific scalar) {
$thing->do_this(@these_args);
print $thing->asString;
}
So I tried a similar thing in Smalltalk:
(some complex expression yielding a non-collection) do: [:this |
this oneMeth.
this twoMeth.
Transcript show: this; cr
].
Oops. no go. But, after a bit of exploring, I see Object>>#in:, which precisely does this!
(some complex expression yielding a non-collection) in: [:this |
this oneMeth.
this twoMeth.
Transcript show: this; cr
].
Yeay!
Obviously, this is no replacement for simply assigning the complex expression to a real method temp, but in a pinch, this seems to be a nice idiom for assigning a value to a temp for a few steps. Cool.
Comments
Object
In Object, add the method...
do: aBlock
^aBlock value: self
How about "doIn:" instead? Added to Object and Collection; that way you can control whether or not you want a "do" or "in" message send to apply to a "blind" receiver whose class isn't known ahead of time.
Using "do" up in Object would be a bad idea IF one was concerned about catching situations where a block was sent to a single object rather than a collection; sometimes you want it one way with just collections and sometimes both are permitted in which case you use "doIn:".
Just a thought to allow for choices that provide powerful expression.
Messages are the key, as if oft mentioned by Alan Kay and others. Part of what means is that messages, by the specifics of their letter-alphanumeric selector, enable you to choose what will happen, but only if that choice is designed into the messaging protocols in a system. For example, adding "doIn:" to the collection protocol of Object and Collection would enable that choice.
Catching errors dynamically enable systems to be built that can't be built with systems that require you to "type" each variable with the classes of the objects that are permitted in them. Catching the message sends to objects that don't understand them is quite important to a free flowing system.
If you don't want flexibility then design a rigid system of methods in the classes. It's not just the amazingly easy to use Smalltalk syntax that makes it a great system, it's the "expressive power" of the messages and classes too!!
Let's add "doIn:" to the upcoming Smalltalk ANSI Standard...
Freely flow your ideas.