another round of call-chaining mystery?

[James Dennett]

kris wrote:
> James Dennett wrote:
>> kris wrote:
> [snip]
>>> There never was any argument of which you claim. I simply noted that
>>> eval-order had been clarified before, using your usage of "eval-order"
>>> from within the same post. If you revisit, you'll see that was actually
>>> referring to call-chaining instead, so there's perhaps a misuse of
>>> terms:
>>>
>>>   Cout.opCall("Hello, ").opCall(Cin.get);
>>>
>>> As you can see, there is only one parameter passed to each call, and
>>> therefore the order of /parameter/ eval is "not at stake here" (as I
>>> noted to Frits). 
>>
>>
>> There are two arguments to the second opCall.  One is
>> the result of Cout.opCall("Hello, ") and the other is
>> the result of Cin.get, and they can be evaluated in
>> either order unless some rule prohibits it.
> 
> I think you'll find that call-chaining does not operate in that manner,
> James? If you look a bit closer, you'll see that the lhs has to be
> evaluated first, simply to get something to deref the rhs. Further,
> there is only one argument permitted to the opCall() itself
> 
> For a fuller description, I suggest you bring it up with Walter instead?

Walter's post in this thread (<eui80b$19hl$1 at digitalmars.com>)
seems to confirm my viewpoint as quoted above.  If you still
don't think so after reading his message, I'd be interested
if you can explain where Walter's explanation differs from
mine.

Regards,

James.