Thanks for your responses. They are very useful. First of all, the
length of this response (and the explanations themselves) speak to the
difficulty casual spec readers have in understanding this syntax. More
specific responses inline.
On Fri, Sep 25, 2009 at 10:29 PM, Cameron McCormack
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:05 PM, Yehuda Katz wrote:
In the ES binding, the properties for these [Replaceable] attributes are
effectively writable, but assigning to them breaks their link to the
original attribute. The
I did not single out Replaceable in my efforts to understand.
Sure, but it is certainly odd and I wanted to recount some of the
history, just so you'd know not to over-attend to it. ;-)
WebIDL comes from OMG IDL, much of the precedent is documented in
various online sites, CORBA books,
On Sep 25, 2009, at 11:43 PM, Yehuda Katz wrote:
Do we disagree that it is a worthy goal to have a specification that
can be understood without having to take a while? I certainly
understand the utility in using something with precedent like IDL (for
implementors). Perhaps the IDL version could
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
Maciej Stachowiak wrote:
I think there are two possible perspectives on what constitutes
magnify[ing] the problem or widening the gap
A) Any new kind of requirement for implementations of object interfaces
that can't be implemented in pure ECMAScript expands the scope of the
problem.
B)
On Fri, Sep 25, 2009 at 11:38 PM, Brendan Eich bren...@mozilla.com wrote:
I did not single out Replaceable in my efforts to understand.
Sure, but it is certainly odd and I wanted to recount some of the history,
just so you'd know not to over-attend to it. ;-)
Ha. Maybe it would be worth
-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 12:20 AM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
I think there are two possible perspectives on what constitutes
magnify[ing] the problem or widening the gap
A) Any new kind of requirement for implementations of object
interfaces
that can't be implemented
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 Fri, 25 Sep 2009, Yehuda Katz wrote:
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)
If there are issues you would like fixed in HTML5 (as opposed to WebIDL),
please
On Fri, 25 Sep 2009, Yehuda Katz wrote:
On Fri, Sep 25, 2009 at 11:38 PM, Brendan Eich bren...@mozilla.com wrote:
I did not single out Replaceable in my efforts to understand.
Sure, but it is certainly odd and I wanted to recount some of the history,
just so you'd know not to over-attend
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
Yehuda Katz:
Ha. Maybe it would be worth putting a note in HTML5. [Replaceable] is
a quirk of history. Do not over-attend to it.
Ian Hickson:
If we start calling out all the quirks of history in HTML5, we'd probably
end up doubling the size of the spec.
OTOH calling out features in Web
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
On Sep 26, 2009, at 3:30 PM, Cameron McCormack wrote:
Yehuda Katz:
Ha. Maybe it would be worth putting a note in HTML5.
[Replaceable] is
a quirk of history. Do not over-attend to it.
Ian Hickson:
If we start calling out all the quirks of history in HTML5, we'd
probably
end up doubling
-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
29 matches
Mail list logo
