Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Sam Ruby
Maciej Stachowiak wrote: On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote: That sounds reasonable. There are really two issues. One is that there are parts of WebIDL that are unused. Another is that the parts of the spec themselves are fairly arcane and very implementor-specific. Consider:

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Anne van Kesteren
On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby ru...@intertwingly.net wrote: Meanwhile, what we need is concrete bug reports of specific instances where the existing WebIDL description of key interfaces is done in a way that precludes a pure ECMAScript implementation of the function. Is

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Sam Ruby
On Fri, Sep 25, 2009 at 5:57 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 25 Sep 2009 11:38:08 +0200, Sam Ruby ru...@intertwingly.net wrote: Meanwhile, what we need is concrete bug reports of specific instances where the existing WebIDL description of key interfaces is done in a way

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Maciej Stachowiak
On Sep 25, 2009, at 2:38 AM, Sam Ruby wrote: Maciej Stachowiak wrote: On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote: That sounds reasonable. There are really two issues. One is that there are parts of WebIDL that are unused. Another is that the parts of the spec themselves are fairly

Re: arguments.callee in Harmony

2009-09-25 Thread Fabian Jakobs
Hi, we have exactly the same problem in qooxdoo http://www.qooxdoo.org. We use arguments.callee.base.call(this, ...); in the same way. Using named functions isn't a solution for us because it would break IE compatibility. In this example ClassB = ClassA.extend({ foo: function foo() {

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Anne van Kesteren
On Fri, 25 Sep 2009 16:26:21 +0200, Mark S. Miller erig...@google.com wrote: To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL-EcmaScript language binding. That is the most essential part of Web IDL for most consumers

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Robin Berjon
Hi Mark, On Sep 25, 2009, at 16:26 , Mark S. Miller wrote: To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL-EcmaScript language binding. I understand the rationale you have to motivate this proposal, I do have a

Re: arguments.callee in Harmony

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 4:14 AM, Fabian Jakobs wrote: foo would leak into the global namespace due to implementation bugs in JScript http://yura.thinkweb2.com/named-function-expressions/. Right now I don't see a good solution for this in strict mode. But strict mode is not supported in

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Brendan Eich
Three distinct topics are being mixed up here: 1. Whether to use WebIDL or some unproposed alternative. 2. Whether to use catchall patterns in new WebIDL-defined interfaces. 3. Whether the JS WebIDL bindings should be standardized by Ecma or W3C. The straw man (0. Whether to remove catchall

RE: arguments.callee in Harmony

2009-09-25 Thread Allen Wirfs-Brock
I thought I had already responded to this, but I guess I missed the send... The Microsoft intent is that when we support ES5 it will conform to the specified FunctionDeclaratiion/FunctionExpression semantics. However, this doesn't mean that ES5 semantics will be unilaterally imposed upon

RE: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Allen Wirfs-Brock
+1 -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Friday, September 25, 2009 9:56 AM To: Anne van Kesteren Cc: public-weba...@w3.org; HTML WG; es-discuss Subject: Re: ECMA TC 39 / W3C HTML and WebApps WG

Re: arguments.callee in Harmony

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 10:31 AM, Charles Jolley wrote: But strict mode is not supported in current or downrev IE. So it is imperative that Microsoft fix these old named function expression name-binding bugs before, or at the same time as, script mode along with all of ES5 are supported in a

Re: arguments.callee in Harmony

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 11:28 AM, Brendan Eich wrote: function compile(...) { eval(var f = function() { + compile_optimized_query(); + }); (Stray ; there in the + chain, oops.) return f; } This can be avoided by putting the var f = outside the eval, if you parenthesize the lambda of

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 12:08 PM, Jonas Sicking wrote: On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich bren...@mozilla.com wrote: My positions are: 1. WebIDL, the bird in the hand (I agree with Sam: go invent something better, come back when you're done). 2. Don't keep perpetuating catchall

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Brendan Eich
I will stop the over-citing madness here and now :-P. The struggle to formalize ArrayLike, which seems like a common goal for ES the core language and for WebIDL's ES bindings, makes me want to give an exception to the catchalls considered harmful for new interfaces injunction. I agree

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Cameron McCormack
Hi Brendan. Brendan Eich: The struggle to formalize ArrayLike, which seems like a common goal for ES the core language and for WebIDL's ES bindings, makes me want to give an exception to the catchalls considered harmful for new interfaces injunction. I agree that indexing into array-likes,

Re: arguments.callee in Harmony

2009-09-25 Thread Charles Jolley
But we can hear feedback, esp. on this list, about hardship adopting strict mode in early ES5 implementations. Mozilla's will be done shortly, and it sounds like WebKit's is coming along quickly too. Feedback based on two interoperable implementations in developers' hands before the ES5

Re: arguments.callee in Harmony

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 2:24 PM, Charles Jolley wrote: But we can hear feedback, esp. on this list, about hardship adopting strict mode in early ES5 implementations. Mozilla's will be done shortly, and it sounds like WebKit's is coming along quickly too. Feedback based on two interoperable

Re: arguments.callee in Harmony

2009-09-25 Thread Charles Jolley
ClassB = ClassA.extend({ foo: function method() { (IS_ES5_STRICT ? method : arguments.callee).base.apply(this, arguments); } }); But why wouldn't you use method always? Or callee, as Ollie suggested. Agree it's annoying to have to add six letters of cruft after the function keyword

Re: arguments.callee in Harmony

2009-09-25 Thread David Flanagan
Charles Jolley wrote: Has anyone considered providing a more explicit way of testing for this? Maybe a constant that is defined somewhere. Strict mode isn't a global on-or-off thing. Some functions can be strict while others aren't. So you can't capture it in a constant. Anyway, that's

Re: arguments.callee in Harmony

2009-09-25 Thread Juriy Zaytsev
On Sep 25, 2009, at 6:22 PM, David Flanagan wrote: Charles Jolley wrote: Has anyone considered providing a more explicit way of testing for this? Maybe a constant that is defined somewhere. Strict mode isn't a global on-or-off thing. Some functions can be strict while others aren't. So

Re: arguments.callee in Harmony

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 3:22 PM, David Flanagan wrote: Charles Jolley wrote: Has anyone considered providing a more explicit way of testing for this? Maybe a constant that is defined somewhere. Strict mode isn't a global on-or-off thing. Some functions can be strict while others aren't. So

Re: arguments.callee in Harmony

2009-09-25 Thread David Flanagan
Brendan Eich wrote: SC.HAS_STRICT = (function() { use strict; return !(function() { return this; }()); }()); (Or something like that. I sure will be happy when there's an implementation to test this stuff against.) You don't need two levels of functions. I just spaced out on the use

Re: arguments.callee in Harmony

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 3:35 PM, Brendan Eich wrote: Otherwise, what you're testing for is something like is this code currently running in strict mode or was this library loaded under strict mode? Thanks for wiping up after me. :-) David kindly pointed out that what I suggested originally

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Waldemar Horwat
Brendan Eich wrote: I will stop the over-citing madness here and now :-P. The struggle to formalize ArrayLike, which seems like a common goal for ES the core language and for WebIDL's ES bindings, makes me want to give an exception to the catchalls considered harmful for new interfaces

Re: arguments.callee in Harmony

2009-09-25 Thread Charles Jolley
These are certainly idioms, especially the first test (as in kick the bucket, something an ES3 programmer could not understand based on the terms in the code alone, only by also reading the ES5 spec or a book based on it). Do they deserve sugar? To me this would be something that should be

Re: arguments.callee in Harmony

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 4:07 PM, Charles Jolley wrote: I would think the most useful test would be is strict mode available not am I currently strict since you can assume the later from the former but not the reverse. Not sure how you can assume the latter from the former: if (! function() {

Re: arguments.callee in Harmony

2009-09-25 Thread Charles Jolley
Not sure how you can assume the latter from the former: if (! function() { use strict; return this; }()) { use strict; /* I'm an ES5 browser and DEFINITELY in strict mode now; doesn't matter what came before me... */ } ___ es-discuss mailing

Re: arguments.callee in Harmony

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 4:22 PM, Charles Jolley wrote: Not sure how you can assume the latter from the former: if (! function() { use strict; return this; }()) { use strict; /* I'm an ES5 browser and DEFINITELY in strict mode now; doesn't matter what came before me... */ } Gotcha -- I

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Krzysztof Maczyński
Do we need a WindowProxy in the core language? I'm not sure, but if not then there has to be some other way of specifying how |this| in global code binds to the outer window rather than the inner (Ecma global). We didn't try to make something up here for ES5. ECMAScript could just

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Maciej Stachowiak
On Sep 25, 2009, at 7:26 AM, Mark S. Miller wrote: To clarify, AFAIK, no one on the EcmaScript committee is proposing that WebIDL itself be moved to ECMA, but rather the WebIDL-EcmaScript language binding. The design of Web IDL itself is highly informed by the ECMAScript language binding -

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Maciej Stachowiak
On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote: I will stop the over-citing madness here and now :-P. The struggle to formalize ArrayLike, which seems like a common goal for ES the core language and for WebIDL's ES bindings, makes me want to give an exception to the catchalls considered

Re: arguments.callee in Harmony

2009-09-25 Thread Jason Orendorff
On Fri, Sep 25, 2009 at 4:24 PM, Charles Jolley char...@sproutit.com wrote: But just to be clear, after all of the discussion here, it appears that the only way to implement a call super pattern in ES5 (without resorting to closures as Breton suggested) would be to use the following magic

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Maciej Stachowiak
On Sep 25, 2009, at 3:34 PM, Krzysztof Maczyński wrote: Do we need a WindowProxy in the core language? I'm not sure, but if not then there has to be some other way of specifying how |this| in global code binds to the outer window rather than the inner (Ecma global). We didn't try to make

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 4:57 PM, Maciej Stachowiak wrote: On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote: So if you are doing more ArrayLike interfaces, let's keep talking. Don't let at least my catchalls-considered-harmful statements stop progress on ArrayLikes. Perhaps when catchalls are

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Waldemar Horwat
Maciej Stachowiak wrote: Perhaps when catchalls are considered for ECMAScript, there could b a way to encapsulate the specific pattern of index access, so you can have magical getters and setters for all index properties (integer numbers in range to be an array index) without having to install

WebIDL

2009-09-25 Thread Yehuda Katz
At the urging of some folks, I've poked around WebIDL and have a few observations. I'll use the Window object from HTML as a prop here (it is reproduced, in full, below): 1. There are a number of ECMAScript-specific extensions here that have obscure names and non-obvious behavior. For instance,

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Mark S. Miller
On Fri, Sep 25, 2009 at 8:27 PM, Mark S. Miller erig...@google.com wrote: OTOH, if our resolution of the need for array-like generic indexes is to allow overloading of [], then perhaps the resolution for new APIs is to annotate them somehow, to distinguish them from the

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-25 Thread Mark S. Miller
On Fri, Sep 25, 2009 at 8:00 PM, Yehuda Katz wyc...@gmail.com wrote: Something worth keeping in mind when thinking about low-traffic lists is the context-switch cost for casual contributors. Even very-low-traffic lists carry a very large historical and conceptual overhead that must be loaded

Re: arguments.callee in Harmony

2009-09-25 Thread Mark S. Miller
On Fri, Sep 25, 2009 at 2:24 PM, Charles Jolley char...@sproutit.com wrote: PS. Is there an official way to detect that I am running code in ES5 strict mode? I can't find it in the spec. To summarize: A conventional pattern for testing Am I in = ES5 strict mode? is if (function(){return

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-25 Thread 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

Re: WebIDL

2009-09-25 Thread Cameron McCormack
Hi Yehuda. Yehuda Katz: 1. There are a number of ECMAScript-specific extensions here that have obscure names and non-obvious behavior. For instance, understanding [Replaceable] readonly is non-trivial. In fact, [Replaceable] readonly has somewhat confusing semantics, in that the attribute is

Re: WebIDL

2009-09-25 Thread Cameron McCormack
Boris Zbarsky: This I'd like to second. I spent a day or so last week tracing through the overload resolution stuff and the general what happens when someone tries to call a method flow, and it's very difficult to follow: lots of jumping back and forth required, for example. I agree that the

Re: WebIDL

2009-09-25 Thread Maciej Stachowiak
On Sep 25, 2009, at 10:29 PM, Cameron McCormack wrote: unsigned long doesn’t map exactly to Number. Assigning a Number to an unsigned long attribute does truncation, for example: http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long The case could be made for “float”, which maps to

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Cameron McCormack
Maciej Stachowiak: Now, there may be pragmatic reasons for avoiding catchall getters and setters: … Mark S. Miller: Yes. As an obvious example of #3, what happens when a Storage http://dev.w3.org/html5/webstorage/ key is toString? It’s a good example of something that’s not obvious,

Re: WebIDL

2009-09-25 Thread Cameron McCormack
Maciej Stachowiak: JS numbers are IEEE doubles, not singles (modulo the indistinguishability of different NaNs and other such details). Right, my mistake. -- Cameron McCormack ≝ http://mcc.id.au/ ___ es-discuss mailing list es-discuss@mozilla.org