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 |
In reply to this post by Stéphane Ducasse
execute or evaluate?
On 17 August 2011 23:17, Stéphane Ducasse <[hidden email]> 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. |
In reply to this post by Philippe Marschall-2-3
this is a convenience methods
On 17 August 2011 23:29, Philippe Marschall <[hidden email]> 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. |
In reply to this post by Igor Stasenko
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 <[hidden email]> 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. |
In reply to this post by stephane ducasse
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 > > |
In reply to this post by Philippe Marschall-2-3
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:? 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 |
In reply to this post by Stéphane Ducasse
On 17 August 2011 23:45, Stéphane Ducasse <[hidden email]> 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 <[hidden email]> 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. |
In reply to this post by Henrik Sperre Johansen
On 17 August 2011 23:57, Henrik Sperre Johansen
<[hidden email]> 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. |
In reply to this post by Henrik Sperre Johansen
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 #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 <[hidden email]> wrote:
|
In reply to this post by Stéphane Ducasse
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 |
Free forum by Nabble | Edit this page |