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 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
On Sep 28, 2009, at 10:12 AM, Allen Wirfs-Brock wrote:
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Robin Berjon
There is no old version.
Right, this is v1. What previous W3C API specifications had relied on
was
It would be pretty nice if the language bindings of WebIDL were
available in pure ES, where possible. To some degree, that is not
currently possible (in ES3), but it will be a lot better in ES5. I
think it might actually be possible to get a large degree of
completion just using the JavaScript
I meant actually written. Being able to see actual code that implemented
pieces of the IDL in ES would make some of the more complex interactions
more obvious (I suspect).
-- Yehuda
On Tue, Sep 29, 2009 at 3:28 AM, Maciej Stachowiak m...@apple.com wrote:
On Sep 28, 2009, at 11:34 PM, Yehuda
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
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
On Mon, 28 Sep 2009 17:20:27 +0200, Mark S. Miller erig...@google.com
wrote:
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
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Robin Berjon
There is no old version.
Right, this is v1. What previous W3C API specifications had relied on
was either OMG IDL, or the common lore understanding that people were
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 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
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]]
On 9/27/09 3:30 AM, Brendan Eich wrote:
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
On 9/27/09 2:28 AM, Maciej Stachowiak wrote:
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.
Huh. Gecko hasn't supported this, and we haven't had
On Sep 27, 2009, at 11:14 AM, Brendan Eich wrote:
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure
ECMAScript. The current proposal does
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:23 PM, Boris Zbarsky wrote:
On 9/27/09 3:30 AM, Brendan Eich wrote:
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
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 12:37 PM, Boris Zbarsky wrote:
On 9/27/09 2:28 AM, Maciej Stachowiak wrote:
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.
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
-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 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
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
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 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: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.
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
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
35 matches
Mail list logo
