[squeak-dev] #cull: protocol
josh at schwa.ca
Sun Feb 21 18:09:16 UTC 2010
(I'm not on the Pharo list; could someone who is cross-post this?)
I understand the purpose, but I think the name is horrible.
Even #value:value: is somewhat confusing, when you think about it. #value makes perfect sense, and #value: is a natural extension meaning "answer the value of the block with the given arg". But #value:value: makes it seem like the word "value" now refers to the arguments instead of the operation to be performed by the receiver. We have a sort of pun, where the word "value" is being used in two senses at once. Oh well, it's too late to change now, and I don't have a better suggestion anyway.
The message #cull: does not say what it means: "answer the value of the block with the given arg, but ignoring the arg if the block doesn't take that many arguments". There is little correspondence between the meaning of the word "cull" in English and the semantics of the invoked method. Sure, programmers can learn what it means, just like they can learn what "extern" means in C. The problem is that we're essentially adding a keyword to our language. Smalltalkers often brag, rightfully, about how few keywords there are in the language. We should avoid introducing what are essentially keywords into core protocols (they're actually worse than keywords, because at least keywords can be highlighted by a pretty-printer).
#valueWithPossibleArgs: is awkward, but at least the name has some relationship with what it means, plus people already know what it means. What about instead using the protocol #valueWithPossibleArg:, #valueWithPossibleArg:value:, etc. ?
On Feb 21, 2010, at 9:00 AM, Levente Uzonyi wrote:
> I uploaded a new version of the Kernel package (Kernel-ul.403) to the Inbox. It adds the #cull: protocol to BlockClosure. #cull: is pretty much like #value:, but can be send to blocks without arguments. The implementation contains #cull:, #cull:cull:, #cull:cull:cull: and #cull:cull:cull:cull:. There's also a new version of KernelTests (KernelTests-ul.140) which implements tests for these methods.
> The pros and cons of these methods can be found here: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/022151.html
> (though I think portability will be an advantage soon).
> If nobody disagrees I'll add these to the Trunk in a few days.
More information about the Squeak-dev