- From: <bugzilla@jessica.w3.org>
- Date: Tue, 14 Feb 2012 19:23:18 +0000
- To: public-script-coord@w3.org
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