Re: [Pharo-dev] Implementing cull:cull: in symbol
Le 20 juin 2014 02:16, David T. Lewis le...@mail.msen.com a écrit : On Thu, Jun 19, 2014 at 11:24:33AM -0300, Esteban A. Maringolo wrote: Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Hi Esteban, I am an American English speaker, and I have never used the word 'cull' in conversation or in writing. I recognize it as a real word, but I had to look it up in a dictionary to see what it means. Dave Extensive usage here... http://stargate.wikia.com/wiki/Culling You'll see cull: with a new eye now :-p Phil
Re: [Pharo-dev] Implementing cull:cull: in symbol
On 20 Jun 2014, at 22:59, stepharo steph...@free.fr wrote: On 19/6/14 14:08, Henrik Johansen wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion +1 I’m not telling to implement #value:value: but #cull:cull: which is equivalent to #value: so instead of [ :var | var name ] I can use just #name Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry
[Pharo-dev] Implementing cull:cull: in symbol
Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko
Re: [Pharo-dev] Implementing cull:cull: in symbol
I believe this was already discussed long ago, with a decision not to go further that #cull: (or #value:) on Symbol, some even find that too much from a design perspective. I like writing code like #(1 2 3) collect: #asString especially interactively, since it is less verbose. In what situation did you encounter a need to add #cull:cull: to Symbol ? On 19 Jun 2014, at 13:42, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko
Re: [Pharo-dev] Implementing cull:cull: in symbol
For example in Spec’s ListModel there is a thing called displayBlock:. And I have to write `list displayBlock: [ :package | package name ]`, while I think that `list displayBlock: #name` is clear enough, but the block receives #cull:cull: Uko On 19 Jun 2014, at 13:52, Sven Van Caekenberghe s...@stfx.eu wrote: I believe this was already discussed long ago, with a decision not to go further that #cull: (or #value:) on Symbol, some even find that too much from a design perspective. I like writing code like #(1 2 3) collect: #asString especially interactively, since it is less verbose. In what situation did you encounter a need to add #cull:cull: to Symbol ? On 19 Jun 2014, at 13:42, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko
Re: [Pharo-dev] Implementing cull:cull: in symbol
On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Implementing cull:cull: in symbol
The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry
Re: [Pharo-dev] Implementing cull:cull: in symbol
In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Implementing cull:cull: in symbol
On 19 Jun 2014, at 15:47, Tudor Girba tu...@tudorgirba.com wrote: In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: “value:value:” else if possible: “value:” else “value” So this can work for block. But maybe cull: has different philosophy Uko The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Implementing cull:cull: in symbol
Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Regards, -- Esteban. ps: I'm a big fan of having a valuable protocol, implemented by both Symbol and BlockClosure (and MessageSend), and I miss this behavior in Pharo. Esteban A. Maringolo 2014-06-19 11:14 GMT-03:00 Yuriy Tymchuk yuriy.tymc...@me.com: On 19 Jun 2014, at 15:47, Tudor Girba tu...@tudorgirba.com wrote: In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: “value:value:” else if possible: “value:” else “value” So this can work for block. But maybe cull: has different philosophy Uko The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Implementing cull:cull: in symbol
http://www.wordreference.com/es/translation.asp?tranword=cull yet, it does not looks like having anything to do with executing a block with optional parameters :) On 19 Jun 2014, at 11:24, Esteban A. Maringolo emaring...@gmail.com wrote: Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Regards, -- Esteban. ps: I'm a big fan of having a valuable protocol, implemented by both Symbol and BlockClosure (and MessageSend), and I miss this behavior in Pharo. Esteban A. Maringolo 2014-06-19 11:14 GMT-03:00 Yuriy Tymchuk yuriy.tymc...@me.com: On 19 Jun 2014, at 15:47, Tudor Girba tu...@tudorgirba.com wrote: In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: “value:value:” else if possible: “value:” else “value” So this can work for block. But maybe cull: has different philosophy Uko The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Implementing cull:cull: in symbol
A stretch for rational behind cull: We are 'culling' the excess variables passed to the block (roughly equivalent to killing animals when there are too many of them). On Thu, Jun 19, 2014 at 7:31 AM, Esteban Lorenzano esteba...@gmail.com wrote: http://www.wordreference.com/es/translation.asp?tranword=cull yet, it does not looks like having anything to do with executing a block with optional parameters :) On 19 Jun 2014, at 11:24, Esteban A. Maringolo emaring...@gmail.com wrote: Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Regards, -- Esteban. ps: I'm a big fan of having a valuable protocol, implemented by both Symbol and BlockClosure (and MessageSend), and I miss this behavior in Pharo. Esteban A. Maringolo 2014-06-19 11:14 GMT-03:00 Yuriy Tymchuk yuriy.tymc...@me.com: On 19 Jun 2014, at 15:47, Tudor Girba tu...@tudorgirba.com wrote: In other engines where we want scripting to be used, we use a cull: or value: with a prefix. In the case of Spec, this could be specCull:cull:. This could be used as an extension of Symbol without spawning religious wars :). Yes, also I can use a block with 1 param. The thing is that as far as I understand cull:cull: means: if possible: “value:value:” else if possible: “value:” else “value” So this can work for block. But maybe cull: has different philosophy Uko The funny thing is that in all these engines that do define special value: like methods, the implementation looks exactly the same. Perhaps this should tell us that it would be worth having it by default. Doru On Thu, Jun 19, 2014 at 2:16 PM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: The thing is that cull:cull: can be used on block with 1 parameter. If you consider symbol as a block with one parameter then it will work in the same style. In other words: methods that use value:value: want to ensure that they are working with 2 param block. Methods that use cull:cull: don’t care what is there, but allow you to customise the result with up to 2 parameters. With symbol you can customise it with 1 parameter. Uko On 19 Jun 2014, at 14:08, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On 19 Jun 2014, at 1:42 , Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, maybe we should implement #cull:cull: in symbol so that it will call #cull:? Because this looks correct, if block has 1 parameter, then #cull:cull: boils down to #value:, but when we have a symbol instead, we have an exception. I can open an issue and implement that stuff, but I want a feedback from the conceptual point of view. Uko #cull: is supposed to be the equivalent to the #value: protocol, where the parameter is optional. Symbol has no #value:value: message, hence it should have no #cull:cull: either. You could argue it should implement both, with value:value: polymorphic to the block [:a :b | a perform: theSymbol with: b ]. but cull:cull: would then mean equivalence to: for #+ [:a :b | a + b] for #squared [:a | a self] And I don’t see how that’d be intuitive/useful enough to warrant inclusion Considering the sole reason cull: on Symbol exists, is to allow select: etc. to be written using cull so the block arg is optional, but still do aCollection collect: #mySymbol, the closest equivalent would be . aCollection sort: # / aCollection inject: 0 into: #+ which, while might be nice, both have no use for cull:cull: in the same manner: aCollection inject: 0 into: #squared - [:sub :next | sub squared] ??? The whole who is the receiver, what’s going on»-factor of cull:cull: on symbol is non-intuitive enough that at least I feel it’s better to write out the block explicitly. Cheers, Henry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Implementing cull:cull: in symbol
On Thu, Jun 19, 2014 at 11:24:33AM -0300, Esteban A. Maringolo wrote: Can somebody please tell me the semantic difference between #cull: and #value: ? 'Cull' is not a word I ever used in any english based conversation :) Hi Esteban, I am an American English speaker, and I have never used the word 'cull' in conversation or in writing. I recognize it as a real word, but I had to look it up in a dictionary to see what it means. Dave
