[Bug 15986] Specify exactly how and when ECMAScript arguments are evaluated

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15986

--- Comment #3 from Aryeh Gregor <ayg@aryeh.name> 2012-02-14 19:23:16 UTC ---
(In reply to comment #1)
> So this is all specified already.  The question is whether the specification
> makes sense.  For example, does it make sense to run the overload algorithm on
> overload sets of size 1 to start with?

Hmm, okay.  I do think that one desirable property of whatever we wind up with
is that nothing should be evaluated more than once.  By "evaluated" I guess I
mean "toString() or valueOf() is called" -- anything that might have side
effects or be nondeterministic.

This is currently the case per spec, right?  The only thing that will call
those is conversion to IDL values, and that's only in the argument resolution
algorithm?  If so, the current spec seems reasonable enough.

The second test-case from comment #0 indicates that Gecko doesn't follow the
spec, doesn't it?  The overload resolution algorithm should throw before any
arguments are converted to IDL types, so it should output "unchanged".


Observation: in practice, almost no operations are overloaded, and the few that
are could be converted to have optional arguments or use union types.  What's
an example of a place where we need overloading at all?  For instance, in HTML,
the following canvas operations

  void drawImage(HTMLImageElement image, double dx, double dy);
  void drawImage(HTMLImageElement image, double dx, double dy, double dw,
double dh);
  void drawImage(HTMLImageElement image, double sx, double sy, double sw,
double sh, double dx, double dy, double dw, double dh);
  void drawImage(HTMLCanvasElement image, double dx, double dy);
  void drawImage(HTMLCanvasElement image, double dx, double dy, double dw,
double dh);
  void drawImage(HTMLCanvasElement image, double sx, double sy, double sw,
double sh, double dx, double dy, double dw, double dh);
  void drawImage(HTMLVideoElement image, double dx, double dy);
  void drawImage(HTMLVideoElement image, double dx, double dy, double dw,
double dh);
  void drawImage(HTMLVideoElement image, double sx, double sy, double sw,
double sh, double dx, double dy, double dw, double dh);

could become

 void drawImage(
   (HTMLImageElement or HTMLCanvasElement or HTMLVideoElement) image,
   double x1, double y1,
   optional double w1, optional double h1,
   optional double x2, optional double y2,
   optional double w2, optional double h2);

with an extra couple lines of prose to handle the corner cases.  I don't
suppose we could just get rid of overloading?

(In reply to comment #2)
> The evaluation order of the arguments to a function by the caller is fully
> specified by the ECMAScript specification.  The issue here seems to be the
> order in which the formal parameters (the values of the arguments after they
> have been evaluated as part of performing the ECMAScript call) are accessed by
> the callee in a manner that possibly produces observable side-effects. 

Do you mean this?  http://es5.github.com/#x11.2.4  That calls GetValue() on the
arguments.  If I'm reading things correctly, calling GetValue() on {valueOf:
function() { return 'foo'; }} will not invoke the valueOf function.  So any
calls of that function will be only because of WebIDL.

> However, for the actual web api functions it isn't clear how you would define
> the ordering of observable side-effect if you don't want to use an algorithmic
> specification.

Operations in WebIDL operate on IDL values, and accessing IDL values can't have
side effects, I don't think.  E.g., if you have an operation that accepts a lon
and pass {valueOf: function() { return 7 }}, WebIDL will call ToNumber() on it,
and then pass the IDL value '7' to the actual operation.  So I think we only
have to worry about WebIDL here.

> In summary, ECMAScript already does what it needs to do.  I believe (but this
> needs confirmation) that Web IDL does what it needs to do. However,
> implementations may not yet conform to the current  Web IDL specification. Once
> that occurs, it still leave every function defined using Web IDL as being
> responsible for specifying observable side-effect order.

It seems to me that Boris is right: everything is well-defined, but it's not
clear that WebIDL's definitions are what we actually want.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 14 February 2012 19:23:20 UTC