The Trunk: Kernel-cmm.819.mcz

Chris Muller uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-cmm.819.mcz

==================== Summary ====================

Name: Kernel-cmm.819
Author: cmm
Time: 6 November 2013, 3:42:56.929 pm
UUID: df349ca4-09ec-4a78-b10b-bc2ca823d8cd
Ancestors: Kernel-nice.818

- Fix #numArgs for MessageSend's whose arguments have not yet been set.

=============== Diff against Kernel-nice.818 ===============

Item was changed:
  ----- Method: MessageSend>>numArgs (in category 'accessing') -----
  numArgs
+ ^ selector numArgs!
- "Answer the number of arguments in this message"
-
- ^arguments size!

On 6 November 2013 21:43,  <[hidden email]> wrote:
Under what conditions would we have a MessageSend without arguments?
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.

frank

> Under what conditions would we have a MessageSend without arguments?

MessageSend class>>#receiver:selector:.  Seaside does this with
keyword messages to setup callbacks.  The arguments aren't known at
the time the callback is set up.

> 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.

On 7 November 2013 00:02, Chris Muller <[hidden email]> wrote:
>> Under what conditions would we have a MessageSend without arguments?
>
> MessageSend class>>#receiver:selector:.  Seaside does this with
> keyword messages to setup callbacks.  The arguments aren't known at
> the time the callback is set up.

I mis-spoke. I thought you meant the change to be "when arguments is
_uninitialised", but #receiver:selector: does do that.

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!

(Of course you could also ^ arguments size + 1...)

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.
>

> 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.

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.

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.
>>
>

On 7 November 2013 16:32, Chris Muller <[hidden email]> wrote:
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