call chaining clarified

[Derek Parnell]

On Thu, 29 Mar 2007 23:14:09 -0700, kris wrote:


> Thank you for that clarification, Walter.
> 
> You note that the inner opCall will be evaluated before the outer one; 
> how is x.one(a).two(b).three(c) tranformed?

I'm guessing ...

   three( two( one(x, a), b), c);

thus either 'x' or 'a' is done first, then the other
 then either 'one' or 'b', then the other
 then either 'two' or 'c', then the other
 and finally 'three'
   
>> I suggest that at a minimum, if you wish to retain the current design, 
>> build a test into the test suite that verifies the required order of 
>> evaluation.
>> 
>> It's possible that in the future, to ensure source code portability of 
>> D, that the order of evaluation will become fixed. Such a change is a 
>> fair amount of work to accomplish, and will incur a runtime penalty (the 
>> implementation defined order allows the compiler to rearrange things to 
>> minimize register pressure). Even if the order was fixed, it still might 
>> not be in the right order for call chaining to work as your design needs 
>> it to.
> 
> Do you mean in terms of generic call-chaining, or that example 
> specifically? For example, will the code x.one().two().three() always 
> execute one() before two() ?

I think it would. But in the case of  "x.one(a).two(b)" then you can't be
sure if 'one' or 'b' will be evaluated first.

>> I also suggest that, with the maturing of the variadic template 
>> capability of D, using it will side step the order of evaluation problem 
>> completely. It'll still be an aesthetically pleasing design to the user.
> 
> That's certainly a possibility, Walter, but call-chaining is surely 
> expected to operate in an orderly fashion regardless of whether it is 
> used as an IO interface or not? For example, what happens if two() were 
> to return a different object for three() to be applied against? It would 
> surely be incorrect to generate code whereby three() were called against 
> x instead? In other words, for call chaining to operate correctly the 
> following pseudocode should likely hold true:
> 
> # auto result = x.one().two().three();
> 
> auto tmp1 = x.one();
> auto tmp2 = tmp1.two();
> auto result = tmp2.three();
> 
> Is that incorrect?

I think Walter is saying that a test similar to ...

  auto tmpA = x.one(a).two(b).three(c);
  auto tmp1 = x.one(a);
  auto tmp2 = tmp1.two(b);
  auto tmp3 = tmp2.three(c);
  assert( tmpA is tmp3);

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
30/03/2007 4:25:04 PM