At 14:12 -0400 8/31/98, Travis Griggs wrote: SNIP...
I'd like to make a third kind of suggestion for your list. Don't mix blocks and other values. Make the protocol different. For example:
at: key ifAbsentPut: anObject self at: key ifAbsent: [ self at: key put: anObject ]
at: key ifAbsentPutValue: aBlock self at: key ifAbsent: [ self at: key put: aBlock value ]
Another effect of this suggestion is that it still allows putting blocks into dictionaries as values, while suggestions 1 and 2 do not.
Why don't we just add types to Smalltalk! Seriously people, that's what all of these messages are starting to look like. I can just see some of my methods in the future:
at: aKey ifAbsentPutValueOfOneArgBlockThatWontReturnNil: aBlock
Not that I necessarily have a better solution :). But it worries me when I see messages whose keyword parts are basically types. A little of this is OK, but I think it should be used sparingly.
I don't think of this as a type issue, but an evaluation issue. When is the parameter evaluated: when first passed, when about to insert it into the collection (lazy evaluation), or never? I claim one needs all three.
#at:ifAbsentPut:, as implemented elsewhere, evaluates the parameter expression before the message is sent. If it is a block then the block is put into the collection.
#at:ifAbsentPut:, as proposed, would allow a block and evaluate its contents before putting the result into the collection. However, this prevents actually putting a block into the collection without an ugly contortion:
dict at: aKey ifAbsentPut: [ [ blockCode ] ]
#at:ifAbsentPutValueOf: makes this explicit. One is not putting the block into the collection, but the result of evaluating the block.
Note that, for consistancy, if the thrid example is considered wrong, one should then make #at:put: have the same properties as #at:ifAbsentPut:. If a block is passed it is evaluated before putting its value into the collection.
Dave _______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.