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
On Sep 27, 2009, at 21:44 , Mark S. Miller wrote:
On Sun, Sep 27, 2009 at 12:35 PM, Robin Berjon ro...@berjon.com
wrote:
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
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
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
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
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
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
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
On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote:
See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but
note objections there, as well as some alternatives discussed in es-discuss@mozilla.org
.
Thanks for the reference. That does look similar to my suggestion.
However, it
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
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
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
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.
is: It's impossible to write a
conforming JS engine that browsers will
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
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
-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
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
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
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
Allen Wirfs-Brock:
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
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
On Sep 26, 2009, at 3:36 PM, Cameron McCormack wrote:
Allen Wirfs-Brock:
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
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
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
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
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
-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
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
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
-Original Message-
From: Cameron McCormack [mailto:c...@mcc.id.au]
...
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
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
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
On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote:
[much appreciated information snipped -- thanks!]
I really don't see how the review process and accountability could
be much more open for the development of Web IDL elsewhere, nor is
the burden on reviewers that large... it would simply be
33 matches
Mail list logo
