[Pharo-project] what are the comments of cull: cull: cull:cull: and friends?
Hi guys I would like to get a better system and I would appreciate some comments for these methods. Stef
I wrote cull: anArg "Execute the receiver with one or zero argument. [ 1 + 2 ] cull: 5 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 " ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg] cull: firstArg cull: secondArg "Execute the receiver with two or less arguments. [ 1 + 2 ] cull: 5 cull: 6 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 [ :x | 1+ 2 + x] cull: 5 cull: 3 returns 8 [ :x : y | 1+ y + x] cull: 5 cull: 2 returns 8 " ^numArgs < 2 ifTrue: [self cull: firstArg] ifFalse: [self value: firstArg value: secondArg] cull: firstArg cull: secondArg cull: thirdArg "Execute the receiver with three or less arguments. Check cull:cull: for examples" ^numArgs < 3 ifTrue: [self cull: firstArg cull: secondArg] ifFalse: [self value: firstArg value: secondArg value: thirdArg] cull: firstArg cull: secondArg cull: thirdArg cull: fourthArg "Execute the receiver with four or less arguments. Check cull:cull: for examples" ^numArgs < 4 ifTrue: [self cull: firstArg cull: secondArg cull: thirdArg] ifFalse: [self value: firstArg value: secondArg value: thirdArg value: fourthArg] Will add a bug entry Stef
On 17.08.2011 22:17, Stéphane Ducasse wrote:
I wrote
cull: anArg "Execute the receiver with one or zero argument.
[ 1 + 2 ] cull: 5 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 " ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg]
So it's like #valueWithPossibleArgument:? Why do we need two methods that do the same thing? Cheers Philippe
this is a convenience methods On 17 August 2011 23:29, Philippe Marschall <kustos@gmx.net> wrote:
On 17.08.2011 22:17, Stéphane Ducasse wrote:
I wrote
cull: anArg    "Execute the receiver with one or zero argument.
   [ 1 + 2 ] cull: 5        returns 3    [ :x | 1+ 2 + x] cull: 5        returns 8    "    ^numArgs = 0        ifTrue: [self value]        ifFalse: [self value: anArg]
So it's like #valueWithPossibleArgument:? Why do we need two methods that do the same thing?
Cheers Philippe
-- Best regards, Igor Stasenko AKA sig.
On 17.08.2011 22:29, Philippe Marschall wrote:
On 17.08.2011 22:17, Stéphane Ducasse wrote:
I wrote
cull: anArg "Execute the receiver with one or zero argument.
[ 1 + 2 ] cull: 5 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 " ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg]
So it's like #valueWithPossibleArgument:? Almost. cull: raises error if given blocks with too many args, valueWithPossibleArgument(s): evaluates with the extra args as nil. Why do we need two methods that do the same thing? Because valueWithPossibleArguments was there first, and we can't simply remove it. cull is more natural to use in 99.9% of the cases.
Also, #cull: protocol only goes up to 4 arguments, mirroring #value: (#cullWithArguments: not being present is mostly an oversight though... ) Cheers, Henry
On 17 August 2011 23:57, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 17.08.2011 22:29, Philippe Marschall wrote:
On 17.08.2011 22:17, Stéphane Ducasse wrote:
I wrote
cull: anArg     "Execute the receiver with one or zero argument.
    [ 1 + 2 ] cull: 5         returns 3     [ :x | 1+ 2 + x] cull: 5         returns 8     "     ^numArgs = 0         ifTrue: [self value]         ifFalse: [self value: anArg]
So it's like #valueWithPossibleArgument:?
Almost. cull: raises error if given blocks with too many args, valueWithPossibleArgument(s): evaluates with the extra args as nil.
 Why do we need two methods that do the same thing?
Because valueWithPossibleArguments was there first, and we can't simply remove it. cull is more natural to use in 99.9% of the cases.
Also, #cull: protocol only goes up to 4 arguments, mirroring #value: (#cullWithArguments: not being present is mostly an oversight though... )
yes yes, cull is cool. no need to provide more arguments :) Also, it is easier to use and remember, because every time i need to use valueWithPossibleBlahblah i always forgetting the right selector and need to lookup the implementation. -- Best regards, Igor Stasenko AKA sig.
On 17.08.2011 22:57, Henrik Sperre Johansen wrote:
On 17.08.2011 22:29, Philippe Marschall wrote:
On 17.08.2011 22:17, Stéphane Ducasse wrote:
I wrote
cull: anArg "Execute the receiver with one or zero argument.
[ 1 + 2 ] cull: 5 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 " ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg]
So it's like #valueWithPossibleArgument:? Almost. cull: raises error if given blocks with too many args, valueWithPossibleArgument(s): evaluates with the extra args as nil. Why do we need two methods that do the same thing? Because valueWithPossibleArguments was there first, and we can't simply remove it. cull is more natural to use in 99.9% of the cases.
Also, #cull: protocol only goes up to 4 arguments, mirroring #value: (#cullWithArguments: not being present is mostly an oversight though... )
So we #valueWithPossibleArgument:? Cheers Philippe
On Aug 18, 2011, at 8:52 44AM, Philippe Marschall wrote:
On 17.08.2011 22:57, Henrik Sperre Johansen wrote:
On 17.08.2011 22:29, Philippe Marschall wrote:
On 17.08.2011 22:17, Stéphane Ducasse wrote:
I wrote
cull: anArg "Execute the receiver with one or zero argument.
[ 1 + 2 ] cull: 5 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 " ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg]
So it's like #valueWithPossibleArgument:? Almost. cull: raises error if given blocks with too many args, valueWithPossibleArgument(s): evaluates with the extra args as nil. Why do we need two methods that do the same thing? Because valueWithPossibleArguments was there first, and we can't simply remove it. cull is more natural to use in 99.9% of the cases.
Also, #cull: protocol only goes up to 4 arguments, mirroring #value: (#cullWithArguments: not being present is mostly an oversight though... )
So we #valueWithPossibleArgument:?
Cheers Philippe #valueWithPossibleArgument: / #valueWithPossibleArgs: / #valueWithEnoughArguments: all execute the block with nil args if passed too few. #cull:'s raise an error. Other than that, they are equivalent from a users POV, yes.
Cheers, Henry
What about making explicit in the comment that the arg is ignored if not needed? Something like cull: anArg "Execute the receiver with one or zero argument. If the receiver needs less than one argument, the argument is ignored. ..." Guille On Thu, Aug 18, 2011 at 4:17 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
On Aug 18, 2011, at 8:52 44AM, Philippe Marschall wrote:
On 17.08.2011 22:57, Henrik Sperre Johansen wrote:
On 17.08.2011 22:29, Philippe Marschall wrote:
On 17.08.2011 22:17, Stéphane Ducasse wrote:
I wrote
cull: anArg "Execute the receiver with one or zero argument.
[ 1 + 2 ] cull: 5 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 " ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg]
So it's like #valueWithPossibleArgument:? Almost. cull: raises error if given blocks with too many args, valueWithPossibleArgument(s): evaluates with the extra args as nil. Why do we need two methods that do the same thing? Because valueWithPossibleArguments was there first, and we can't simply remove it. cull is more natural to use in 99.9% of the cases.
Also, #cull: protocol only goes up to 4 arguments, mirroring #value: (#cullWithArguments: not being present is mostly an oversight though... )
So we #valueWithPossibleArgument:?
Cheers Philippe #valueWithPossibleArgument: / #valueWithPossibleArgs: / #valueWithEnoughArguments: all execute the block with nil args if passed too few. #cull:'s raise an error. Other than that, they are equivalent from a users POV, yes.
Cheers, Henry
execute or evaluate? On 17 August 2011 23:17, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I wrote
cull: anArg     "Execute the receiver with one or zero argument.
    [ 1 + 2 ] cull: 5         returns 3     [ :x | 1+ 2 + x] cull: 5         returns 8     "     ^numArgs = 0         ifTrue: [self value]         ifFalse: [self value: anArg]
cull: firstArg cull: secondArg     "Execute the receiver with two or less arguments.
    [ 1 + 2 ] cull: 5 cull: 6         returns 3     [ :x | 1+ 2 + x] cull: 5         returns 8     [ :x | 1+ 2 + x] cull: 5 cull: 3         returns 8     [ :x : y | 1+ y + x] cull: 5 cull: 2         returns 8     "     ^numArgs < 2         ifTrue: [self cull: firstArg]         ifFalse: [self value: firstArg value: secondArg]
cull: firstArg cull: secondArg cull: thirdArg     "Execute the receiver with three or less arguments. Check cull:cull: for examples"
    ^numArgs < 3         ifTrue: [self cull: firstArg cull: secondArg]         ifFalse: [self value: firstArg value: secondArg value: thirdArg]
cull: firstArg cull: secondArg cull: thirdArg cull: fourthArg     "Execute the receiver with four or less arguments. Check cull:cull: for examples"     ^numArgs < 4         ifTrue: [self cull: firstArg cull: secondArg cull: thirdArg]         ifFalse: [self value: firstArg value: secondArg value: thirdArg value: fourthArg]
Will add a bug entry
Stef
-- Best regards, Igor Stasenko AKA sig.
I prefer execute :) because evaluate looks like you don't run fast and generate possibly assembly on the fly. I stopped long time ago to use evaluate because people also think that Smalltalk is slow because of that evaluation.... silly idiots but they are out there. Stef (Ze mass educator) On Aug 17, 2011, at 10:29 PM, Igor Stasenko wrote:
execute or evaluate?
On 17 August 2011 23:17, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I wrote
cull: anArg "Execute the receiver with one or zero argument.
[ 1 + 2 ] cull: 5 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 " ^numArgs = 0 ifTrue: [self value] ifFalse: [self value: anArg]
cull: firstArg cull: secondArg "Execute the receiver with two or less arguments.
[ 1 + 2 ] cull: 5 cull: 6 returns 3 [ :x | 1+ 2 + x] cull: 5 returns 8 [ :x | 1+ 2 + x] cull: 5 cull: 3 returns 8 [ :x : y | 1+ y + x] cull: 5 cull: 2 returns 8 " ^numArgs < 2 ifTrue: [self cull: firstArg] ifFalse: [self value: firstArg value: secondArg]
cull: firstArg cull: secondArg cull: thirdArg "Execute the receiver with three or less arguments. Check cull:cull: for examples"
^numArgs < 3 ifTrue: [self cull: firstArg cull: secondArg] ifFalse: [self value: firstArg value: secondArg value: thirdArg]
cull: firstArg cull: secondArg cull: thirdArg cull: fourthArg "Execute the receiver with four or less arguments. Check cull:cull: for examples" ^numArgs < 4 ifTrue: [self cull: firstArg cull: secondArg cull: thirdArg] ifFalse: [self value: firstArg value: secondArg value: thirdArg value: fourthArg]
Will add a bug entry
Stef
-- Best regards, Igor Stasenko AKA sig.
On 17 August 2011 23:45, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I prefer execute :) because evaluate looks like you don't run fast and generate possibly assembly on the fly.
:)
I stopped long time ago to use evaluate because people also think that Smalltalk is slow because of that evaluation.... silly idiots but they are out there.
Hehe.. Smalltalk is fast.
Stef (Ze mass educator)
On Aug 17, 2011, at 10:29 PM, Igor Stasenko wrote:
execute or evaluate?
On 17 August 2011 23:17, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I wrote
cull: anArg     "Execute the receiver with one or zero argument.
    [ 1 + 2 ] cull: 5         returns 3     [ :x | 1+ 2 + x] cull: 5         returns 8     "     ^numArgs = 0         ifTrue: [self value]         ifFalse: [self value: anArg]
cull: firstArg cull: secondArg     "Execute the receiver with two or less arguments.
    [ 1 + 2 ] cull: 5 cull: 6         returns 3     [ :x | 1+ 2 + x] cull: 5         returns 8     [ :x | 1+ 2 + x] cull: 5 cull: 3         returns 8     [ :x : y | 1+ y + x] cull: 5 cull: 2         returns 8     "     ^numArgs < 2         ifTrue: [self cull: firstArg]         ifFalse: [self value: firstArg value: secondArg]
cull: firstArg cull: secondArg cull: thirdArg     "Execute the receiver with three or less arguments. Check cull:cull: for examples"
    ^numArgs < 3         ifTrue: [self cull: firstArg cull: secondArg]         ifFalse: [self value: firstArg value: secondArg value: thirdArg]
cull: firstArg cull: secondArg cull: thirdArg cull: fourthArg     "Execute the receiver with four or less arguments. Check cull:cull: for examples"     ^numArgs < 4         ifTrue: [self cull: firstArg cull: secondArg cull: thirdArg]         ifFalse: [self value: firstArg value: secondArg value: thirdArg value: fourthArg]
Will add a bug entry
Stef
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 17 Aug 2011, at 13:45 , Stéphane Ducasse wrote:
I prefer execute :) because evaluate looks like you don't run fast and generate possibly assembly on the fly. I stopped long time ago to use evaluate because people also think that Smalltalk is slow because of that evaluation....
I'm happy for Smalltalk to be fast! However, the method on block is called value: , not execute: So it makes sense to speak of evaluating a block, rather than executing it. Unless we change value: to execute: everywhere :-) Andrew
On 17.08.2011 22:11, stephane ducasse wrote:
Hi guys
I would like to get a better system and I would appreciate some comments for these methods.
Stef Execute receiving block with as many arguments as it requires. This allows us to write blocks more concisely when we are not necessarily interested in all the available arguments.
#cull fills the same need as #valueWith[Possible/Enough]Args: , but does not require creating an Array with the arguments, and will raise an error if block has more arguments than provided rather than pass nil in the extraneous ones. Hence, from where the block is provided, they look almost the same, but where the block is executed, the code is usually cleaner. Cheers, Henry
thanks I will be in the Block chapter I'm revising now :) On Aug 17, 2011, at 10:47 PM, Henrik Sperre Johansen wrote:
On 17.08.2011 22:11, stephane ducasse wrote:
Hi guys
I would like to get a better system and I would appreciate some comments for these methods.
Stef Execute receiving block with as many arguments as it requires. This allows us to write blocks more concisely when we are not necessarily interested in all the available arguments.
#cull fills the same need as #valueWith[Possible/Enough]Args: , but does not require creating an Array with the arguments, and will raise an error if block has more arguments than provided rather than pass nil in the extraneous ones. Hence, from where the block is provided, they look almost the same, but where the block is executed, the code is usually cleaner.
Cheers, Henry
participants (8)
-
Andrew P. Black -
Guillermo Polito -
Henrik Johansen -
Henrik Sperre Johansen
-
Igor Stasenko -
Philippe Marschall -
stephane ducasse -
Stéphane Ducasse