Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 29, 2009, at 08:17 , Maciej Stachowiak wrote: On Sep 28, 2009, at 2:06 AM, Robin Berjon wrote: On Sep 28, 2009, at 01:19 , Maciej Stachowiak wrote: On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote: If at all possible I'd rather it went to LC ASAP, and if needed that new stuff be done in a branched document. Based on the conversation so far, I expect Web IDL in roughly its current state would not survive Last Call. Which is fine, being grilled through LC is progress. I would just like to avoid piling up even more things that it needs to do. We're supposed to do our best to address likely objections before Last Call. Hence the AP part of ASAP. -- Robin Berjon - http://berjon.com/
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 28, 2009, at 2:06 AM, Robin Berjon wrote: On Sep 28, 2009, at 01:19 , Maciej Stachowiak wrote: On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote: If at all possible I'd rather it went to LC ASAP, and if needed that new stuff be done in a branched document. Based on the conversation so far, I expect Web IDL in roughly its current state would not survive Last Call. Which is fine, being grilled through LC is progress. I would just like to avoid piling up even more things that it needs to do. We're supposed to do our best to address likely objections before Last Call. - Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 28, 2009, at 01:19 , Maciej Stachowiak wrote: On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote: If at all possible I'd rather it went to LC ASAP, and if needed that new stuff be done in a branched document. Based on the conversation so far, I expect Web IDL in roughly its current state would not survive Last Call. Which is fine, being grilled through LC is progress. I would just like to avoid piling up even more things that it needs to do. -- Robin Berjon - http://berjon.com/
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Mon, Sep 28, 2009 at 2:02 AM, Robin Berjon ro...@berjon.com wrote: I'm not sure what you're getting at here. WebIDL isn't just for HTML5, it's used throughout WebApps and DAP, and by a number of other groups as well, which have deliverables at various levels of completion. By depending on WebIDL, a lot of these cannot move forward along the process until WebIDL itself moves ahead. Don't get me wrong, I'm not in the least hostile to an ES5 binding. I just don't want to rush into it and have a knock-on effect on the timeliness of a bunch of other people's work. Good point. I was indeed thinking only of HTML5. Other things being equal, it would seem the best way for these other projects to avoid blocking on WebIDL would be for them to rely only on the previous version of WebIDL. Of course, other things are never equal. Why do these other projects need a new version of WebIDL? -- Cheers, --MarkM
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
Allen Wirfs-Brock: The internal methods such as [[Delete]] aren't an actual extension mechanism. They are a specification device used to define the semantics of ECMAScript. As such they are subject to change (there are significant changes in the ES5 spec.) and could even completely disappear if some edition of the ES specification chooses to adopt a different specification technique (which has been discussed). OK, that is indeed what I’m hearing from you guys. “Host objects may implement these [internal] methods in any manner unless specified otherwise” in ES3 doesn’t sound like it’s particularly discouraging of the different behaviour that Web IDL prescribes. Another issue with using specification internal methods as if they were an extension mechanism is that the ECMAScript specifications doesn't define any abstract contracts for them. What are the invariants that every [[Delete]] methods must maintain in order for the entire language to remain sound? It isn't currently defined. Or, defined to be “you can do anything”. Which admittedly isn’t useful if you are indeed trying to maintain some invariants. Within the ES spec. this isn't a big problem because most of the internal methods only have one definition within the ES specification and if there are more than one they have been designed with a unified semantics in mind. Why is functionality that isn't available through native objects needed? For web compatibility, really. If it is possible to define Java bindings for WebIDL that don't require extending the Java language why isn't it possible to approach JavaScript in the same manner (for new APIs, I understand the legacy issues). Java really doesn’t have those compatibility issues. Ignoring the legacy issues, assuming we have ES5 to build on, then yeah it seems like most things can be done (from Maciej’s quick analysis). The array like objects do seem like a useful pattern for authors to use, though. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 11:16 PM, Cameron McCormack wrote: OK, that is indeed what I’m hearing from you guys. “Host objects may implement these [internal] methods in any manner unless specified otherwise” in ES3 doesn’t sound like it’s particularly discouraging of the different behaviour that Web IDL prescribes. That is regrettable ES1-era language, written to accommodate the host objects found prominently in IE due to too-low-level COM integration. It should have come with color commentary advising against exploiting the barn-door-sized loopholes. Why is functionality that isn't available through native objects needed? For web compatibility, really. Web Storage is a recent example of something other than web compatibility at work. Imitation of what went before, keystroke- optimization to use the short property reference expression instead of get/put/remove methods, or both, AFAICT. Ignoring the legacy issues, assuming we have ES5 to build on, then yeah it seems like most things can be done (from Maciej’s quick analysis). The array like objects do seem like a useful pattern for authors to use, though. Seems like everyone agrees Array-likes are not the issue. /be
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 8:05 PM, Brendan Eich wrote: On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote: - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. Seems like a strong reason to change to the proposed API to eliminate the need for a new ES language extension. I previously argued for removing the need for catchall deleters from the Web Storage API (since nothing else requires , but other browser vendors (including Mozilla) were happy with it, (including Mozilla) and happy with it leave out some nuance: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014856.html Robert O'Callahan here wrote If overloading delete is too quirky or too hard to implement, then it seems none of the other shorthands should be allowed either. His message adverted to the better course of methodical access instead of property access to Web Storage keyed values. Alas Rob finally gave up at: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014868.html I think the Web Storage key/value reflection as properties is a mistake. Sorry I wasn't reviewing it in time to say so. But it was obviously not a situation everyone was happy with, even ignoring the issue of delete. I accept your corrections as to nuance. At the time I felt like I was fighting a losing battle. The real issue, though, is what to do going forward. and I think now everyone (including I believe Microsoft) has implemented the spec behavior. See prior discussion thread here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html . At this point, since we have multiple deployed implementations of Web Storage, we'd have to investigate whether it's safe to remove this behavior without breaking content. We could try to remove it -- or (what is more likely to go down easily) we could add methods and let the property reflections wither, and vow to avoid repeating this mistake. There are methods, but I'm not optimistic that they will cause property reflection to wither. If the number of places in the Web platform that require custom delete behavior goes from 1 to 2, that's a lot less bad than going from 0 to 1. So it won't accomplish much. However, I missed a spot and it looks like custom deleters are also used by the DOMStringMap interface, which is used to reflect data-* attributes. http://dev.w3.org/html5/spec/Overview.html#domstringmap-0 I don't think anyone has implemented that yet. I believe we could get rid of custom deleters from the Web platform if Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for DOMStringMap. If that happened, I'm sure other browsers and the spec would follow suit. I don't think I can convince my colleagues to remove the behavior from WebKit if Gecko and Trident continue to support it. 2) Ability to support being called (via [[Call]]) without being a Function. Not an issue with the core ES5 semantics. Most ES3/5 section 15 functions have this characteristic. As long as such WebIDL objects are defined similarly to the built-in function they too can have this characteristic. It may well be useful to introduce a mechanism defining such pure functions in the language but it probably isn't necessary to proceed with the WebIDL binding. The important thing to try to avoid is specify a custom [[Call]] I tend to agree that this behavior (and the next 3) are not philosophically problematic, even though they cannot today be implemented in pure ECMAScript. What does typeof say for such a callable object? I think it should probably say object, though that's not compatible with ES3 or current WebKit practice. In what sense are any DOM methods required to be not Functions (native function objects) in the specs? In Netscape of old and Mozilla browsers since 1998, DOM methods are native function objects. This is not an issue for DOM methods. It's an issue for interfaces such as HTMLCollection and HTMLFormElement that support indexing by function call syntax, for legacy compatibility reasons. Constructors like XMLHttpRequest, Option and Image also do not inherit from Function.prototype even though they are callable. This seems winning since developers want not only sane typeof, but .apply/call/bind. It's definitely winning, and it may be possible to apply it to global constructors that are also callable as a future improvement, but it's probably not possible to make HTMLCollection or HTMLFormElement inherit from the Function prototype, and I think it would not be desirable either. We've talked on es-discuss about pure functions (ones without [[Construct]] and .prototype) before: https://mail.mozilla.org/pipermail/es5-discuss/2009-July/002920.html in case you missed the thread. Agreed it's not a big deal. We have a bugzilla.mozilla.org
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote: There are methods, but I'm not optimistic that they will cause property reflection to wither. getItem/setItem/removeItem/key/clear methods, plus .length -- not a balanced name-set stylistically, but usable to avoid collisions (my key is named 'key', heh). Agreed it looks nearly hopeless to herd developers toward always using these methods instead of .myKey, etc. If the number of places in the Web platform that require custom delete behavior goes from 1 to 2, that's a lot less bad than going from 0 to 1. So it won't accomplish much. However, I missed a spot and it looks like custom deleters are also used by the DOMStringMap interface, which is used to reflect data-* attributes. http://dev.w3.org/html5/spec/Overview.html#domstringmap-0 I don't think anyone has implemented that yet. Horses still out the barn door and we didn't close it yet, I'm not sure who to blame except us (would be barn-door closers, possibly in charge of those horses -- but perhaps they're not even ours!). I believe we could get rid of custom deleters from the Web platform if Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for DOMStringMap. If that happened, I'm sure other browsers and the spec would follow suit. I don't think I can convince my colleagues to remove the behavior from WebKit if Gecko and Trident continue to support it. I'll see what the relevant Mozilla WebAPI hackers think, if they're not reading this thread. At this point I suspect it is too late, in the sense that we'd be taking risks with plaform compatibility we don't accept in our release version/compatibility plan. What does typeof say for such a callable object? I think it should probably say object, though that's not compatible with ES3 or current WebKit practice. ES3 lets host objects choose function or object or any old string (Implementation-dependent). ES5 says: Object (native or host and does implement [[Call]]) - function Object (host and does not implement [[Call]]) - Implementation-defined except may not be undefined, boolean, number, or string. This is not an issue for DOM methods. It's an issue for interfaces such as HTMLCollection and HTMLFormElement that support indexing by function call syntax, for legacy compatibility reasons. Constructors like XMLHttpRequest, Option and Image also do not inherit from Function.prototype even though they are callable. Right, thanks for clarifying that. DOM collection types, even if callable (VBScript was to blame) are not function objects, and DOM constructors, unlike chapter 15 built-in ES constructors, are not generally function objects. This seems winning since developers want not only sane typeof, but .apply/call/bind. It's definitely winning, and it may be possible to apply it to global constructors that are also callable as a future improvement, but it's probably not possible to make HTMLCollection or HTMLFormElement inherit from the Function prototype, and I think it would not be desirable either. Why not for HTMLFormElement? Agree for HTMLCollection. Perhaps it's sufficient to provide an API for altering the [[Call]] and [[Construct]] behavior of an existing object without a first- class syntax, following in the spirit of defineOwnProperty(). Something like foo.defineOperation(construct, funcToCallWhenConstructing). This would address all of points 2 to 5, for ECMAScript implementations that wish to precisely replicate DOM behavior. This approach could also be used for index getters/ setters/has-testers, general catchall getters/setters/has-testers, removing either one of call or construct while retaining the other, making call and construct do different things, and perhaps other useses. And using a method instead of first-class syntax would let scripts feature-test for this capability. See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but note objections there, as well as some alternatives discussed in es-disc...@mozilla.org . A MOP for catchalls that stratifies the hooks into mirage (by analogy to mirror-based reflection) objects may be forthcoming; we'll see (I'll let the experts say more). A dark horse, at this point, but hey, those other horses made it out of the barn ;-). For simple things like non-constructor functions one might prefer a declarative form. As an implementor and a developer, I would -- mutation is a bitch to optimize in a VM, and to contain in one's user code. Also the meta-programming API seems likely to be more verbose than the (still elusive, but stipulate that it must be concise) hypothetical declarative syntax. Ye olde Image and Option, at least, act like most built-in constructors by constructing when called, at least in Gecko and I think IE -- but not in WebKit (I just tested). My
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 27, 2009, at 12:30 AM, Brendan Eich wrote: On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote: What does typeof say for such a callable object? I think it should probably say object, though that's not compatible with ES3 or current WebKit practice. ES3 lets host objects choose function or object or any old string (Implementation-dependent). ES5 says: Object (native or host and does implement [[Call]]) - function Object (host and does not implement [[Call]]) - Implementation-defined except may not be undefined, boolean, number, or string. I think it may be a compatibility risk for HTMLCollection to report its type as function instead of object. This is not an issue for DOM methods. It's an issue for interfaces such as HTMLCollection and HTMLFormElement that support indexing by function call syntax, for legacy compatibility reasons. Constructors like XMLHttpRequest, Option and Image also do not inherit from Function.prototype even though they are callable. Right, thanks for clarifying that. DOM collection types, even if callable (VBScript was to blame) are not function objects, and DOM constructors, unlike chapter 15 built-in ES constructors, are not generally function objects. This seems winning since developers want not only sane typeof, but .apply/call/bind. It's definitely winning, and it may be possible to apply it to global constructors that are also callable as a future improvement, but it's probably not possible to make HTMLCollection or HTMLFormElement inherit from the Function prototype, and I think it would not be desirable either. Why not for HTMLFormElement? Agree for HTMLCollection. By HTMLFormElement I mean the actual instances that represent the form element in an HTML DOM, not the pseudo-constructor object named HTMLFormElement on the window object. HTML5 gives it callable indexing. It already inherits from HTMLElement (and Element and Node) so it's unclear how to stick Function into its prototype chain. And I don't think we want call(), apply() and bind() methods to start appearing on form elements. Perhaps it's sufficient to provide an API for altering the [[Call]] and [[Construct]] behavior of an existing object without a first- class syntax, following in the spirit of defineOwnProperty(). Something like foo.defineOperation(construct, funcToCallWhenConstructing). This would address all of points 2 to 5, for ECMAScript implementations that wish to precisely replicate DOM behavior. This approach could also be used for index getters/ setters/has-testers, general catchall getters/setters/has-testers, removing either one of call or construct while retaining the other, making call and construct do different things, and perhaps other useses. And using a method instead of first-class syntax would let scripts feature-test for this capability. See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but note objections there, as well as some alternatives discussed in es-disc...@mozilla.org . Thanks for the reference. That does look similar to my suggestion. However, it looks like the invoke and construct methods there are intended for calling a property of the object (or invoking it as a constructor), rather than for applying call or construct to the object itself. A MOP for catchalls that stratifies the hooks into mirage (by analogy to mirror-based reflection) objects may be forthcoming; we'll see (I'll let the experts say more). A dark horse, at this point, but hey, those other horses made it out of the barn ;-). For simple things like non-constructor functions one might prefer a declarative form. As an implementor and a developer, I would -- mutation is a bitch to optimize in a VM, and to contain in one's user code. Also the meta-programming API seems likely to be more verbose than the (still elusive, but stipulate that it must be concise) hypothetical declarative syntax. Sure - one way a MOP approach helps is by moving past debates about the most elegant syntax, by having unapologetically inelegant syntax. Then maybe once the capability is there, someone can invent good syntax later. Ye olde Image and Option, at least, act like most built-in constructors by constructing when called, at least in Gecko and I think IE -- but not in WebKit (I just tested). My testing seems to indicate not in IE. Likewise for XMLHttpRequest. We should probably specify one way or the other whether these are callable and stick to it. I am indifferent as to which behavior we standardize on. Me too, except if I had to do it all over again I would have worked harder to make function-ness orthogonal to prototype, a mixin if you will. I wish functions and constructors were different kinds of things. I'm not sure if that's the same kind of idea you're talking about. At this point,
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote: On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote: I'm musing a bit here, bear with me. If we only hack incrementally, and preserve backward compatibility with frankly dumb (or merely hasty) design decisions (many mine!) then we'll probably make less progress than if we try to rationalize old and new in a better systematic design. That's a little too abstract for me to tell if I agree or not. Shortest-path evolution can walk uphill only a little bit at a time, and get stuck at local minimal points in a design space, when over the big hill is a much better, richer valley to evolve in. This path dependency problem bits many real-world systems. I experience this point as hard and painful, like concrete -- it' s not abstract. I've been around too long to ignore it, as it's all around us on the web, and it has been since 1994 if not earlier. Compatibility concerns in the form of graceful degradation or progressive enhancement are not unmixed blessings. More coherent stacks from Microsoft, Adobe, and Sun can rightly claim to solve problems more cleanly and simply than the web. Of course these stacks have other problems, mainly from being single-sourced if not proprietary, but also from not progressing compatibly, and for other reasons I won't digress on. But there's no point pretending the Web (ES, DOM, etc.) is an example of a well-designed toolkit for building user-facing distributed apps! But we're not really free to discard compatibility. So I'm not that excited about the exciting opportunities we could have if we did. The Web is a duct tape design but it works. Dropping compatibility would kill one of its biggest advantages. Systems that discard compatibility can also deliver an unusable Second System, especially when designed by committee. I would point to certain W3C specs that chose to break compatibility with existing practice. They are often not only undeployable but also not very compelling on their own terms. I think compatibility constraints, even though they impose messy and illogical quirks, can also act as a healthy counterweight to flights of design fancy. Constraints make for good art. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 27, 2009, at 12:35 PM, Robin Berjon wrote: On Sep 27, 2009, at 00:36 , Cameron McCormack wrote: Indeed, much of the custom [[Get]] etc. functionality can be turned into ES5 meta-object stuff. A pertinent question is then: should we change Web IDL to specify an ES5 binding (and not ES3) at this point, given that specs depending on it want to advance along the Rec track? I would tend to be rather in disfavour of anything that might cause WebIDL to be delayed in any way. I also think that keeping the ES3 binding is useful (in the short term at least) if only because it is familiar, which might point to building the ES5 one separately. If at all possible I'd rather it went to LC ASAP, and if needed that new stuff be done in a branched document. Based on the conversation so far, I expect Web IDL in roughly its current state would not survive Last Call. - Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 27, 2009, at 4:15 PM, Maciej Stachowiak wrote: On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote: But there's no point pretending the Web (ES, DOM, etc.) is an example of a well-designed toolkit for building user-facing distributed apps! But we're not really free to discard compatibility. So I'm not that excited about the exciting opportunities we could have if we did. The Web is a duct tape design but it works. Dropping compatibility would kill one of its biggest advantages. Sure. You didn't see me proposing dropping Web compatibility (suicide for browser vendors) -- rather, I'm talking about doing end-to-end design as we go, and meeting in the middle. Too many short hops via a standard body incurs high costs in the spec process (some essential, some not) while tending to enshrine mistakes over time due to compatibility. Whereas taking big hops risks mission creep, or mission cliff-dive into second-system death-beach ;-), or even the old mistake of targeting a market foreseen five years out that never arrives (the real world zigged instead of zagging). We've all seen these problems, I think, over our careers. And it's not as if the proprietary languages and stacks can break compatibility excessively (search for Visual Fred). But they can and do provide new and more coherent API-sets that help deprecate old ones. To avoid proprietary stack examples, consider Python's from __future__ import mechanism: http://www.python.org/dev/peps/pep-0236/ This precedent is attractive if one can push out new versions of the language implementation, with carrots to induce people to upgrade, as well as the stick of unsupported ancient versions. It helps that C- Python is source-as-spec, but let's say that is a non-issue with good- enough ES specs. The carrots instead of sticks idea is more critical from what I have seen, for Python and for JavaScript -- we can't get people to stop doing what worked if there's no new and better way (the recent arguments.callee in strict mode thread highlighted this point). Of course, the web is too big to try to get away with deprecation/ obsolescence cycles on any predictable near-term release schedule. Never mind coordination among browser vendors on their next versions -- IE6 is still Out There. But perhaps once past IE6, though, with modern browsers auto-updating, we'll see the downrev implementations go away faster. There's a chance, anyway, from what I see of IE8 replacing IE7, and of course faster updating for other, fresher browsers ;-). If we do see a world where browser version uptake is faster, and the downrev problem shrinks or becomes more tractable somehow, then we will want shinier duct tape without bits of lint and trash stuck to the edges of the tape roll, over time. Every compatibility constraint costs non-linearly when refracted through the whole-language design process. So part of ECMAScript Harmony is not just ES6, a prematurely- triaged, shortest-path evolutionary jump, but longer-term end to end design that ultimately puts the TC39 committee out of the language- extension business by empowering developers to bootstrap new language versions by themselves. Systems that discard compatibility can also deliver an unusable Second System, especially when designed by committee. I would point to certain W3C specs that chose to break compatibility with existing practice. They are often not only undeployable but also not very compelling on their own terms. Agreed. I think compatibility constraints, even though they impose messy and illogical quirks, can also act as a healthy counterweight to flights of design fancy. Constraints make for good art. We seem to have some unnecessary constraints, which are bad for art and science. Let's try to get rid of the foo(i) for foo[i] or foo.item[i] non-mandatory compatibility cruft and see how that goes. /be
RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Yehuda Katz Another way to put my earlier concern is: It's impossible to write a conforming JS engine that browsers will want to use by only following the ES spec - since there's additional, un-speced, behavior that isn't in ES that is necessary in order to construct a browser's DOM. Consider the following scenario: I write an ECMAScript engine that is significantly faster than any existing engine by simply following the ECMAScript spec. A browser maker then wishes to use this engine. This would be impossible without adding additional (hidden) features to the engine to support the DOM. There is nothing in the ECMAScript spec that requires the ability (at the very least) to add native extensions with arbitrary behavior to the engine. Is this a requirement ECMA is comfortable with? No we are not. This is exactly the heart of our concern. The WebIDL ECMAScript binding is not simply a mapping of IDL interface onto standard language features (such as is done for the Java binding). While it has some of that it also defines an extended ECMAScrpt language with new semantics. (and I understand this is mostly a reflection of past (present?) practice of browser implementers). Essentially, the semantics of browser ECMAScript has been arbitrarily split into two independently maintained standards. Language design is not primarily about designing individual isolated features. The hard parts of language design involves the interactions among such features and typically requires making design trade-offs and alteration to ensure that all features compose coherently. If the language specification responsibilities are arbitrarily broken into two uncoordinated activities then it is impossible for either to do the global design that is necessary to have a complete and sound language and specification. TC39 has the language design expertise. W3C has Web API design expertise. If there are language design issues that must be addressed in order to fully specify browser ECMAScript (and there are) then those issues need to be addressed by TC39. Perhaps TC309 has been remiss in the past in addressing these browser specific language design issues. If so, it was probably for historic political and competitive reasons that don't necessarily apply today. That is what we want to fix. Allen Wirfs-Brock Microsoft
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich bren...@mozilla.com wrote: On Sep 25, 2009, at 11:20 PM, Yehuda Katz wrote: On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich bren...@mozilla.com wrote: On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote: Another way to put my earlier concern Sorry, what earlier concern? You are replying to my reply to Doug Schepers on a sub-thread where I didn't see a message from you. So confusing! So many messages! No, you just replied off-topic and rehashed an issue that we all agree needs fixing, seemingly as if I had implied that it wasn't an issue. Although the generous citations of my reply to Doug Schepers that you included of course implied nothing of the kind. Why did you do that? I failed? There are about 100 messages on this topic that I'm reading and trying to digest. There's a whole lot of history involved. In the end, I can only speak for myself, and I can say that I'm personally having a lot of trouble trying to piece things together by looking at the specifications. [big snip] My point is that understanding the semantics of the language as implemented by browser vendors is not possible by reading the language spec. These is not some hypothetical extension, but a mandatory way that ECMAScript implemented for the web must behave. Well, duh. We seem to agree, perhaps vehemently :-/. One last time, for the record: it is a bug in ES specs that you can't follow th The whole point of bothering the HTML WG, public-webapps, and es-discuss about collaboration between Ecma and W3C folks has been to fill gaps between specs and reality. We had some false starts in my view (like trying to move ES WebIDL bindings to Ecma up front, or ever). But the issues laid out in Sam's original cross-post were exactly the gaps between ES specs, HTML5 ones, and browser implementations. At last some of the gaps are filled in HTML5 but not in ways that can be injected directly into ES specs. I'm actually being a bit more radical than you are (perhaps naïvely). I am personally finding WebIDL to be a blocker to understanding. That's because it's another spec that interacts with two other (fairly complex) specs in unpredictable and context-sensitive ways. We should fix the ES specs, and make whatever changes follow to the HTML5 specs. And maybe use WebIDL to constrain host objects. All this has been said on the thread already. Were you not reading the messages I was? I think I saw that in the thread ;) Like I said, my problem is that the interaction between the three specs is making it nearly impossible for a casual reader to understand what's going on. I strongly apologize for not being clearer about that; I'm only starting to fully understand the source of my own confusion. /be -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 25, 2009, at 11:32 PM, Brendan Eich wrote: On Sep 25, 2009, at 11:28 PM, Brendan Eich wrote: We seem to agree, perhaps vehemently :-/. One last time, for the record: it is a bug in ES specs that you can't follow th Sorry, rogue cut before send. it's a bug in ES specs that you can't follow them in order to implement a web-compatible JS engine. Although some of web-compatible JS really does belong in W3C specs, not ES specs, it's clear ES1 pretending there is only one global object did no one any favors. Ditto for execution model and (ultimately) split windows, as Hixie pointed out in raising the conflict between HTML5 and ES1-3 (and now ES5). Just wanted to reassure you, since you seemed to think otherwise, that no one views it as a feature that ES specs don't specify enough. HTML4 specs didn't either. We're getting there. That's right. ES3, HTML4 and DOM Level 2 were all missing many things needed to implement Web-compatible behavior, as well as having requirements that were in some cases contrary to real-world compatibility. Writing a new browser engine based on those specs required multiple years of trial and error and reverse engineering after implementing the spec behavior. Take it from me - that's what we had to do to make WebKit (even building on the foundation of KHTML +KJS, which had already done some of the reverse engineering). ES5, HTML5, Web IDL and some of the Web Apps specs (like XMLHttpRequest and DOM3 Events) are huge steps forward on this front. They don't solve every problem, but they are massive improvements in getting the Web platform correctly specified. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote: No we are not. This is exactly the heart of our concern. The WebIDL ECMAScript binding is not simply a mapping of IDL interface onto standard language features (such as is done for the Java binding). While it has some of that it also defines an extended ECMAScrpt language with new semantics. (and I understand this is mostly a reflection of past (present?) practice of browser implementers). Essentially, the semantics of browser ECMAScript has been arbitrarily split into two independently maintained standards. Is there any concrete concern on this front other than property access catchalls? Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sat, Sep 26, 2009 at 3:36 PM, Cameron McCormack c...@mcc.id.au wrote: Indeed, much of the custom [[Get]] etc. functionality can be turned into ES5 meta-object stuff. A pertinent question is then: should we change Web IDL to specify an ES5 binding (and not ES3) at this point, given that specs depending on it want to advance along the Rec track? Since ES5 will be officially done well ahead of HTML5, I don't see why not. But I do not know what your Rec track constraints imply. -- Cheers, --MarkM
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sat, Sep 26, 2009 at 3:48 PM, Oliver Hunt oli...@apple.com wrote: I would avoid depending on ES5 until there are multiple realworld implementations at least, especially because the interaction between the es5 meta-object functionality and host objects is less than clear at present. Hi Oliver, it is precisely the need to clarify this interaction, as you pointed out in some of your previous posts to es-discuss, that got us to focus on the need for greater coordination at the last EcmaScript meeting. Since, as you say, this interaction is currently unclear, isn't this exactly the kind of problem our standards bodies should be trying to resolve? -- Cheers, --MarkM
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 3:13 PM, Allen Wirfs-Brock wrote: From: Maciej Stachowiak [mailto:m...@apple.com] On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote: ... Essentially, the semantics of browser ECMAScript has been arbitrarily split into two independently maintained standards. Is there any concrete concern on this front other than property access catchalls? Every place the WebIDL ECMAScript binding overrides an ECMAScript specification internal method is a concern as these are special case extensions to the ECMAScript semantics. As language designers we need to understand if these special cases are exemplars of general deficiencies in the language that should be addressed. We have definitely identified catchall property access as such an area. Are there in fact any others? It's a lot more interesting to look at specific examples than to expound on the general principles. See below where I did some study to find other missing capabilities. In particular now that ES5 is finished, WebIDL has a richer language to bind to then it had with ES3. We need a WebIDL binding that maximizes use of ES5 capabilities rather than inventing non-standard (from an ES perspective) language extensions. Updating WebIDL to use ES5 concepts would definitely be worthwhile. At the time Web IDL was started (early 2007 I think) this wasn't a practical option, but it is now. In particular, interfaces that don't have any unusual behavior could be defined as having getters and setters, and should not need to override internal properties at all. This would better highlight the capabilities that are needed to implement the Web platform, but which can't be expressed in the property descriptor formalism. I expect there are relatiively few such capabilities, and little interest in depending on new ones, and therefore we do not really have a general ongoing problem of language design. From a quick scan of WebIDL, I see the following: 1) Catchall getters, putters, deleters, definer. - Variants that can make the catchall check happen either before or after normal property lookup. - General string-based name access and index-only versions. - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. 2) Ability to support being called (via [[Call]]) without being a Function. 3) Ability to support being invoked a constructor (via [[Construct]]) without being a Function. 4) Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement works). 5) Ability to have [[Construct]] do something different than [[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as this. Tentatively, I think all other semantics of Web IDL interfaces can be implemented in pure ES5. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 3:58 PM, Cameron McCormack wrote: Cameron McCormack: Indeed, much of the custom [[Get]] etc. functionality can be turned into ES5 meta-object stuff. A pertinent question is then: should we change Web IDL to specify an ES5 binding (and not ES3) at this point, given that specs depending on it want to advance along the Rec track? Mark S. Miller: Since ES5 will be officially done well ahead of HTML5, I don't see why not. But I do not know what your Rec track constraints imply. For example, Selectors API is at Last Call and will soon be in Candidate Recommendation. I don’t think it can progress further than that until its dependencies move forward. Selectors can't progress to PR/REC until Web IDL is in at least CR state (only one difference in maturity level is allowed for dependencies). I think Web IDL can enter CR with ES5 as is, but it will be considered final as soon as it is published, which is likely to be before Web IDL is ready for Last Call. ECMA process does not have any states between the equivalent of W3C Working Draft and W3C REC (as far as I know). So I don't think this would create any problems for Selectors advancing, other than the time to do the rewrite. On the substantive issue: I do think it would be good to convert Web IDL from ES3 formalisms to ES5 formalisms. While Oliver is right that ES5 has not yet been proven by interoperable implementations, and that some of its methods as defined have a hard time with host objects, I believe that the basic designs of ES5 property descriptors and ES5 getters/setters are sound. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 4:41 PM, Oliver Hunt wrote: The specific problem is that host objects cannot necessarily match the semantics of ES5, and for that reason the interaction of host objects with the ES5 semantics is unclear. I think mapping Web IDL behavior to ES5 property descriptors would help make this interaction more clear. There are additional concerns -- various es5 features expose the underlying implementation mechanisms of the binding -- for instance using get or set properties on a dom binding would require getOwnPropertyDescriptor to expose that implementation detail. getOwnPropertyDescriptor risks leaking implementation details (or at least implementation differences) in any case. The options for Web IDL are: 1) Leave the results of getOwnPropertyDescriptor completely implementation-defined, so different implementations may return different values. 2) Require getOwnPropertyDescriptor to return specific results that expose host object properties as something other than getters or setters. 3) Require getOwnPropertyDescriptor to return specific results that expose host object properties as getters/setters. I reluctantly conclude that #3 is best. #1 leaves behavior unspecified, this needlessly creates the potential for interop problems. #2 conflicts with the way some implementations implement their DOM bindings (e.g. Gecko), meaning extra work for them, and is outright unimplementable in pure ECMAScript. #3 conflicts with the way some implementations implement their DOM bindings (e.g. WebKit) and would mean extra work for them. #3 seems like it has the weakest disadvantages, even though it means extra work for us. However, if we want to allow implementation variance (i.e. policy #1), we could still use ES5 getters and setters as the formal model, but say that host objects implementations may override [[GetOwnProperty]] to give implementation-defined results for host attributes. This would change Web IDL from saying that host object implementations MUST override internal methods to saying they MAY. Regard, Maciej
RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
-Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] I expect there are relatiively few such capabilities, and little interest in depending on new ones, and therefore we do not really have a general ongoing problem of language design. We have an ongoing problem of language design in that all new language features must integrate with existing features. Combinatory feature interactions is one of the larger challenges of language design. From a quick scan of WebIDL, I see the following: 1) Catchall getters, putters, deleters, definer. - Variants that can make the catchall check happen either before or after normal property lookup. - General string-based name access and index-only versions. No comment, I need to come up to speed on the detailed semantic requirements - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. Seems like a strong reason to change to the proposed API to eliminate the need for a new ES language extension. 2) Ability to support being called (via [[Call]]) without being a Function. Not an issue with the core ES5 semantics. Most ES3/5 section 15 functions have this characteristic. As long as such WebIDL objects are defined similarly to the built-in function they too can have this characteristic. It may well be useful to introduce a mechanism defining such pure functions in the language but it probably isn't necessary to proceed with the WebIDL binding. The important thing to try to avoid is specify a custom [[Call]] 3) Ability to support being invoked a constructor (via [[Construct]]) without being a Function. Essentially same as 2 although the standard [[Construct]] requires a [[Call]] so this may need some more thought. 4) Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement works). Possibly the specification of the instanceof operator needs to be made extensible 5) Ability to have [[Construct]] do something different than [[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as this. Similar to 4 regarding extensibility. At least one recent harmony strawman proposal is moving in a direction that may be relevent to 4 and 5. See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors Tentatively, I think all other semantics of Web IDL interfaces can be implemented in pure ES5. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote: -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] I expect there are relatiively few such capabilities, and little interest in depending on new ones, and therefore we do not really have a general ongoing problem of language design. We have an ongoing problem of language design in that all new language features must integrate with existing features. Combinatory feature interactions is one of the larger challenges of language design. From a quick scan of WebIDL, I see the following: 1) Catchall getters, putters, deleters, definer. - Variants that can make the catchall check happen either before or after normal property lookup. - General string-based name access and index-only versions. No comment, I need to come up to speed on the detailed semantic requirements They are pretty similar to the way Array overrides [[DefineOwnProperty]] or the way String defines - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. Seems like a strong reason to change to the proposed API to eliminate the need for a new ES language extension. I previously argued for removing the need for catchall deleters from the Web Storage API (since nothing else requires , but other browser vendors (including Mozilla) were happy with it, and I think now everyone (including I believe Microsoft) has implemented the spec behavior. See prior discussion thread here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html . At this point, since we have multiple deployed implementations of Web Storage, we'd have to investigate whether it's safe to remove this behavior without breaking content. 2) Ability to support being called (via [[Call]]) without being a Function. Not an issue with the core ES5 semantics. Most ES3/5 section 15 functions have this characteristic. As long as such WebIDL objects are defined similarly to the built-in function they too can have this characteristic. It may well be useful to introduce a mechanism defining such pure functions in the language but it probably isn't necessary to proceed with the WebIDL binding. The important thing to try to avoid is specify a custom [[Call]] I tend to agree that this behavior (and the next 3) are not philosophically problematic, even though they cannot today be implemented in pure ECMAScript. 3) Ability to support being invoked a constructor (via [[Construct]]) without being a Function. Essentially same as 2 although the standard [[Construct]] requires a [[Call]] so this may need some more thought. 4) Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement works). Possibly the specification of the instanceof operator needs to be made extensible 5) Ability to have [[Construct]] do something different than [[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as this. Similar to 4 regarding extensibility. At least one recent harmony strawman proposal is moving in a direction that may be relevent to 4 and 5. See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors Interesting. This may provide a way to implement some of these behaviors in pure ECMAScript. The current proposal does allow [[Construct]] without [[Call]], but not [[Call]] and [[Construct]] that both exist but with different behavior. Regards, Maciej
Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
Maciej Stachowiak: - Note: I think catchall deleters are used only by Web Storage and not by other new or legacy interfaces. Allen Wirfs-Brock: Seems like a strong reason to change to the proposed API to eliminate the need for a new ES language extension. When writing Web IDL originally, it didn’t seem at all to me that host objects were a disapproved of mechanism to get functionality that can’t be implemented with native objects. So having a [[Delete]] on a host object be different from the Object [[Delete]] or the Array one seemed fine to me. -- Cameron McCormack ≝ http://mcc.id.au/
