- From: <bugzilla@jessica.w3.org>
- Date: Sat, 05 Mar 2011 01:16:09 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11977 --- Comment #6 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2011-03-05 01:16:08 UTC --- (In reply to comment #5) > > I really would like to avoid defining a source transformation because that > often ends up having far more complicated side-effects than one would expect. > I actually think that in some of these cases source transformation is going to be more reliable and durable then hooking into the spec. language. Basically, the source language and its semantics are managed to ensure a very high degree of backwards compatibility while the internal specification language changes from edition to edition as necessary to define new constructs that are introduced into the language. The internal spec. language historically has not been design with long term stability as a one of its goals. Here is a first cut at defining event handlers as such a transformation: 1 Set the corresponding event handler to null. 2 Set up a script execution environment for JavaScript. 3 Let /body/ be the event handler context attribute's new value. 4 If /body/ is can not be parsed as /FunctionBody/ then abort these steps. 5 Let /F/ and /E/ be the text of any two ECMAScript identifiers that do not occur in /body/. 6 If the element has a form owner let /prefix/ be the string "(function (__F__, __E__) {with (__F__) with (__E__) {" otherwise let /prefix/ be the string "(function (__E__) {with (__E__) {" . 7 Replace all occurrences of "__F__" and "__E__" within /prefix/ with the values of /F/ and /E/ respectively 8 If the attribute is the onerror attribute of the Window object let /funcHeader/ be the string "return function (event, source, fileno) {" otherwise let /funcHeader/ be the string "return function (event) {". 9 Let /handlerMaker/ be a string consisting of the in order concatenation of /prefix/, /funcHeader/, /body/, and "}}})". 10 Create an ECMAScript language script from the node on which the attribute is being set using the string value of /handlerMaker/ as the script source. 11 Let /result/ be the value of the initial code entry-point of this script. If an exception was raised, let /result/ be void instead. 12 If /result/ is void, abort these steps. 13 If the element has a form owner call the function that is the the value of /result/ passing the element's form owner , and the element's object as arguments; 14 otherwise call the function that is the the value of /result/ passing the element's object as the sole argument. 15 Set the corresponding event handler to the value returned by the function call in step 13 or 14. Note: The script text for a /handerMaker/ for an element with a formowner and which is not a onerror attribute of a Window object: // If "__F__" or "__S__" occur in <<body>> they are replaced with identifiers that do no occur. (function (__F__, __S__) { with (__F__) with (__S__) { return function (event) { <<body>> } } }) The result value computed in step 11 is the outer function above. Step 13/14 calls that function to create a closure of the inner function closed over the optional form owner and the element's object. That function is the event handler value. ------------------------ I think the above formulation is clearer and is going to be much more durable. I see minimal risk of unintended side effects and it will be easier to analyze for such than re-purposed ES5 specification pseudo-code. > What I mean by a "hook" is just that the ES spec could say "When a > specification needs to create a foo using a list of arguments bar and a body > baz, it must follow these steps, which return a quux and a gizmo: 1. do > something, 2. do something else, 3. do yet more things". Then instead of having > to reference specific sections or talk about specific grammar constructs, we > can just say "and then create a foo as defined in the ES spec". > > There's a number of places where hooks like that would be useful. The idea of stable interface points between specifications is an interesting one. Where possible, I still think an "as if" transformation to the source language is preferable but for situations where that isn't expressive enough then a stable inter-specification interface my be a good way to make durable connections between specs. However, we should probably continue this discussion somewhere other than in this bug. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Saturday, 5 March 2011 01:16:15 UTC