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
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 wrote:
>
> On Sep 28, 2009, at 11:34 PM, Yehuda Katz wrote:
>
On Sep 28, 2009, at 11:34 PM, Yehuda Katz wrote:
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 larg
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 avai
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 either
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 s
>-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 pe
On Sep 28, 2009, at 17:23 , Anne van Kesteren wrote:
On Mon, 28 Sep 2009 17:20:27 +0200, Mark S. Miller
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
On Mon, 28 Sep 2009 17:20:27 +0200, Mark S. Miller
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 WebIDL.
Of course,
On Mon, Sep 28, 2009 at 2:02 AM, Robin Berjon 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 l
On Sep 27, 2009, at 21:44 , Mark S. Miller wrote:
On Sun, Sep 27, 2009 at 12:35 PM, Robin Berjon
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 term at least) if on
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 sta
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 compatibi
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.
H
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: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
DOMStri
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
pro
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 all
On Sun, 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
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 probl
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 wa
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 s
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-disc...@mozilla.org
.
Thanks for the reference. That does look similar to my suggestion.
However, it l
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]] a
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 cho
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 26, 2009, at 10:55 PM, Allen Wirfs-Brock wrote:
-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 implemente
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 f
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 I
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
> disapp
>-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
>
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 arg
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 ori
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 probl
>-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 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
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
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. There are additional concerns --
various es5 features expose the underlying implementation mechanisms
of the bindi
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 Sat, Sep 26, 2009 at 3:48 PM, Oliver Hunt 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 pre
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 th
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 underst
On Sat, Sep 26, 2009 at 3:36 PM, 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 dependin
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 g
>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 tha
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 defin
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
On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich wrote:
> On Sep 25, 2009, at 11:20 PM, Yehuda Katz wrote:
>
>> On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich
>> wrote:
>>>
>>> On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote:
>>>
>>> Another way to put my earlier concern
>>>
>>> Sorry, what earlier
>-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 th
49 matches
Mail list logo
