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:
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
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
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
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() {
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
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
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
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
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
+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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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() {
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
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
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
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 -
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
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
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
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
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
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,
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
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
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
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
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
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
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
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,
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
46 matches
Mail list logo
