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 <[email protected]> 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 <[email protected]>: >> >> On 19 Jun 2014, at 15:47, Tudor Girba <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> wrote: >>> >>>> >>>> On 19 Jun 2014, at 1:42 , Yuriy Tymchuk <[email protected]> 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" >> >> >
