#cull: protocol
Locked
 
|
Hi,
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. Cheers, Levente |
|
|
(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. ? Cheers, Josh On Feb 21, 2010, at 9:00 AM, Levente Uzonyi wrote: > Hi, > > 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. > > > Cheers, > Levente > |
|
|
2010/2/21 Josh Gargus <[hidden email]>:
> (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. ? > > Cheers, > Josh > > Horrible but compatible... Nicolas > > > On Feb 21, 2010, at 9:00 AM, Levente Uzonyi wrote: > >> Hi, >> >> 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. >> >> >> Cheers, >> Levente >> > > > |
|
|
Now we live in a works of forks, we should expect and cope easily with this minor kind of incompatibility. In Cuis land where small rodents dwell in harmony. I would hope we can forget the compatibility and have a better name, fixing incompatibilities on code import with appropriate tools, the same way as we could also do with := vs _ for assignment, and class renaming on import (poormans namespace implementation) For my cuis derivative (Sooty aka my fork) I don't really think I will be using cull: so it can happily be removed, but added to the load of any package that actually needs it. Keith |
|
|
In reply to this post by Nicolas Cellier
On Feb 21, 2010, at 10:17 AM, Nicolas Cellier wrote: > 2010/2/21 Josh Gargus <[hidden email]>: >> (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. ? >> >> Cheers, >> Josh >> >> > > Horrible but compatible... > > Nicolas True. I didn't read the whole Pharo thread until right now. I assumed that this was a new Pharo protocol that we might be able to agree on a better name for. Now that I see it's an existing VisualWorks protocol, and I agree that it's better to be compatible. (yuck) Cheers, Josh |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |