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 <emaringolo@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.tymchuk@me.com>:
>>
>> On 19 Jun 2014, at 15:47, Tudor Girba <tudor@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.tymchuk@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.johansen@veloxit.no>
>>> wrote:
>>>
>>>>
>>>> On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <yuriy.tymchuk@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"
>>
>>
>