On 7 November 2013 16:32, Chris Muller <asqueaker at gmail.com> wrote:
>> Right. So you're actually saying that (MessageSend receiver: 1
>> selector: #abs) numArgs == 0 instead of the correct 1. I agree. Sorry
>> for the noise!
>
> I have trouble understanding the above.  0 is the correct answer for
> that example, not 1, but this change has no bearing on that example.
>
>> (Of course you could also ^ arguments size + 1...)
>
> Mmm, no.  The idea here is that if a message selector Symbol such as
> #at:put: has a numArgs of 2, and we create a MessageSend based on that
> selector as in:
>
>   MessageSend
>      receiver: myDictionary
>      selector: #at:put:
>
> then its numArgs better be 2, not 0.

Right, right.

Sorry, I confused the arity of a selector with the numArgs of a
selector. Arity matters when considering the "blockification" of
symbols - #(1 2 3) collect: #printString for example.

Your change is exactly the right thing to do. Um, but actually you're
also saying that the above example should be illegal, because it's
impossible to send #at:put: with no arguments. Unless (horror!) you
assume that "no args" means "all args are nil". You could do that by
having #receiver:selector: call self receiver: rcvr selector: sel
arguments: ((1 to: sel numArgs) collect: [:i | nil]). But that would
suck.

> MessageSends are sometimes used interchangeably with Blocks:
>
>    [ :key :value | myDictionary at: key put: value ]
>
> because they're easier to serialize, but either one can be sent
> #value:value: at some point in the future.

Yes. Er, ok. I always considered MessageSend to be a reflective
operation, reifying the idea of sending a message (hence the name).
Also, of course, a MessageSend closes over strictly less than a block.
Maybe it's roughly analogous to a _clean_ block?

frank

> HTH.
>
>
>> frank
>>
>>>> We have three proper constructors that create fully initialised
>>>> MessageSends, so I'd rather hope (quite possibly in vain) that noone
>>>> creates MessageSends through #new directly. It doesn't look like the
>>>> base image does so.
>>>
>>
>