[squeak-dev] #valueWithEnoughArguments: vs #valueWithPossibleArgs: ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] #valueWithEnoughArguments: vs #valueWithPossibleArgs: ?

Igor Stasenko
I using the
#valueWithEnoughArguments:
in my project
but i found that BlockClosure doesn't implements that in 3.10 image i
updated from trunk.

There is, however
#valueWithPossibleArgs: anArray

But its a bit different , because it ensuring that block will be
evaluated even if you passing not enough arguments to it.
Strange design choice, btw:

valueWithPossibleArgs: anArray

        ^numArgs = 0
                ifTrue: [self value]
                ifFalse:
                        [self valueWithArguments:
                                (numArgs = anArray size
                                        ifTrue: [anArray]
                                        ifFalse:
                                                [numArgs > anArray size
                                                        ifTrue: [anArray, (Array new: numArgs - anArray size)]
                                                        ifFalse: [anArray copyFrom: 1 to: numArgs]])]

Does it makes sense to pass 'anArray, (Array new: numArgs - anArray
size)'  at all, because
blocks usually using all arguments they expecting, and there is 99.9%
probability that passing nils to it will lead to errors.
But passing them in such style will make people wonder, where these
nils came from.


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: #valueWithEnoughArguments: vs #valueWithPossibleArgs: ?

Igor Stasenko
Oh, sorry, i just found that #valueWithPossibleArgs:  resembles the
same behavior, i.e. fills rest of arguments array with nils if there
is not enough.

So, the question mainly is that these two methods make each other
redundant, and one of them should be removed.

2009/7/25 Igor Stasenko <[hidden email]>:

> I using the
> #valueWithEnoughArguments:
> in my project
> but i found that BlockClosure doesn't implements that in 3.10 image i
> updated from trunk.
>
> There is, however
> #valueWithPossibleArgs: anArray
>
> But its a bit different , because it ensuring that block will be
> evaluated even if you passing not enough arguments to it.
> Strange design choice, btw:
>
> valueWithPossibleArgs: anArray
>
>        ^numArgs = 0
>                ifTrue: [self value]
>                ifFalse:
>                        [self valueWithArguments:
>                                (numArgs = anArray size
>                                        ifTrue: [anArray]
>                                        ifFalse:
>                                                [numArgs > anArray size
>                                                        ifTrue: [anArray, (Array new: numArgs - anArray size)]
>                                                        ifFalse: [anArray copyFrom: 1 to: numArgs]])]
>
> Does it makes sense to pass 'anArray, (Array new: numArgs - anArray
> size)'  at all, because
> blocks usually using all arguments they expecting, and there is 99.9%
> probability that passing nils to it will lead to errors.
> But passing them in such style will make people wonder, where these
> nils came from.
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: #valueWithEnoughArguments: vs #valueWithPossibleArgs: ?

Igor Stasenko
2009/7/25 Igor Stasenko <[hidden email]>:
> Oh, sorry, i just found that #valueWithPossibleArgs:  resembles the
> same behavior, i.e. fills rest of arguments array with nils if there
> is not enough.
>
oops. i meant #valueWithEnoughArguments: in above. Sorry for flooding :)

> So, the question mainly is that these two methods make each other
> redundant, and one of them should be removed.
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: #valueWithEnoughArguments: vs #valueWithPossibleArgs: ?

Nicolas Cellier
Yeah, I discovered these strange customs with
http://bugs.squeak.org/view.php?id=7352
To me, the whole API looks hackish and messy, but it seems to be used,
so will be hard to remove...

2009/7/25 Igor Stasenko <[hidden email]>:

> 2009/7/25 Igor Stasenko <[hidden email]>:
>> Oh, sorry, i just found that #valueWithPossibleArgs:  resembles the
>> same behavior, i.e. fills rest of arguments array with nils if there
>> is not enough.
>>
> oops. i meant #valueWithEnoughArguments: in above. Sorry for flooding :)
>
>> So, the question mainly is that these two methods make each other
>> redundant, and one of them should be removed.
>>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: #valueWithEnoughArguments: vs #valueWithPossibleArgs: ?

David Goehrig
On Sat, Jul 25, 2009 at 7:37 AM, Nicolas Cellier <[hidden email]> wrote:
Yeah, I discovered these strange customs with
http://bugs.squeak.org/view.php?id=7352
To me, the whole API looks hackish and messy, but it seems to be used,
so will be hard to remove...

The reason they're used is that they are the easiest way to create methods which do the right thing with optional parameters. Now perhaps the "right thing" to do would be add a feature to the parser that allowed methods to "degrade" such that:

foo:withBar:andNarf:  

can be

foo:withBar:

and

foo:

or event possibly

foo

rather than having to write 4 separate methods.  It is incredibly useful when you have say block closures stuck in a dictionary that has the block closures swapped out based on the behavior of those blocks.  Where would you ever use such at thing?  Poker playing AI!  Seriously, if you're implementing a system that can play a game like "Follow the Queen" , the rules of the game change based on what cards are showing.  The easiest way to implement this is to swap out  individual rules when some events happen.  

But discussions like this go nowhere fast :)  For example:


and


actually its a shame the discussion hasn't been more vigorous :)

Dave


-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/