Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
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 into one's brain when responding.
On Fri, Sep 25, 2009 at 8:00 PM, Yehuda Katz <wycats at 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 into one's brain when responding.
Given the reactions in this thread, it seems unlikely that the WebIDL->EcmaScript language bindings will be transferred from W3C to
ECMA. I reluctantly withdraw the suggestion. If it stays at W3C, I think a separate public list open to non-members really is needed. If not or until then, please continue to cc all correspondence about this language binding to es-discuss.
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 scenario: I write an ECMAScript engine that is significantly faster than any existing engine by simply following the ECMAScript spec. A browser maker then wishes to use this engine. This would be impossible without adding additional (hidden) features to the engine to support the DOM. There is nothing in the ECMAScript spec that requires the ability (at the very least) to add native extensions with arbitrary behavior to the engine.
Is this a requirement ECMA is comfortable with?
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 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.
This is a problem to fix. No one is arguing that it's not a problem.
What's the real topic?
Consider the following scenario: I write an ECMAScript engine that is significantly faster than any existing engine by simply following the ECMAScript spec. A browser maker then wishes to use this engine. This would be impossible without adding additional (hidden) features to the engine to support the DOM. There is nothing in the ECMAScript spec that requires the ability (at the very least) to add native extensions with arbitrary behavior to the engine.
The ES spec allows extensions, but it cannot require them without the
extensions being no longer extensions in any sense, rather as
specified parts of the normative core language. Again I don't know
what your point here is.
Is this a requirement ECMA is comfortable with?
What requirement? Your scenario? I have no idea where it came from,
but it doesn't follow from anything you cited (cited again below).
If you mean we need to specify multiple globals, split windows,
execution model, etc. -- that's what I've been saying on the main
thread since the first message, and what Sam's transcription of a
private message from me tried to say.
Still not sure what your point is,
On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich <brendan at 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 sub-thread where I didn't see a message from you.
So confusing! So many messages!
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.
This is a problem to fix. No one is arguing that it's not a problem. What's the real topic?
The real problem is that for people who are not implementing this stuff, it is extremely difficult to track down and piece together all of the semantics. It would seem reasonable to go look at the ECMAScript spec to understand ECMAScript semantics, but as it turns out, it's also necessary to read HTML5 and WebIDL. I have no objection to needing to read the HTML5 spec to understand how the DOM works. I object to having to read HTML5 to understand how ECMAScript works (which is currently necessary).
Consider the following scenario: I write an ECMAScript engine that is significantly faster than any existing engine by simply following the ECMAScript spec. A browser maker then wishes to use this engine. This would be impossible without adding additional (hidden) features to the engine to support the DOM. There is nothing in the ECMAScript spec that requires the ability (at the very least) to add native extensions with arbitrary behavior to the engine.
The ES spec allows extensions, but it cannot require them without the extensions being no longer extensions in any sense, rather as specified parts of the normative core language. Again I don't know what your point here is.
My point is that understanding the semantics of the language as implemented by browser vendors is not possible by reading the language spec. These is not some hypothetical extension, but a mandatory way that ECMAScript implemented for the web must behave.
Is this a requirement ECMA is comfortable with?
What requirement? Your scenario? I have no idea where it came from, but it doesn't follow from anything you cited (cited again below). If you mean we need to specify multiple globals, split windows, execution model, etc. -- that's what I've been saying on the main thread since the first message, and what Sam's transcription of a private message from me tried to say. Still not sure what your point is, /be
I'm sorry.
On Sep 25, 2009, at 11:20 PM, Yehuda Katz wrote:
On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich <brendan at 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 sub-thread where I didn't see a message from you.So confusing! So many messages!
No, you just replied off-topic and rehashed an issue that we all agree
needs fixing, seemingly as if I had implied that it wasn't an issue.
Although the generous citations of my reply to Doug Schepers that you
included of course implied nothing of the kind.
Why did you do that?
[big snip]
My point is that understanding the semantics of the language as implemented by browser vendors is not possible by reading the language spec. These is not some hypothetical extension, but a mandatory way that ECMAScript implemented for the web must behave.
Well, duh.
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
The whole point of bothering the HTML WG, public-webapps, and es-
discuss about collaboration between Ecma and W3C folks has been to
fill gaps between specs and reality. We had some false starts in my
view (like trying to move ES WebIDL bindings to Ecma up front, or
ever). But the issues laid out in Sam's original cross-post were
exactly the "gaps" between ES specs, HTML5 ones, and browser
implementations. At last some of the gaps are filled in HTML5 but not
in ways that can be injected directly into ES specs.
We should fix the ES specs, and make whatever changes follow to the
HTML5 specs. And maybe use WebIDL to constrain "host objects". All
this has been said on the thread already. Were you not reading the
messages I was?
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't
follow them in order to implement a web-compatible JS engine."
Although some of "web-compatible JS" really does belong in W3C specs,
not ES specs, it's clear ES1 pretending there is only one global
object did no one any favors. Ditto for execution model and
(ultimately) split windows, as Hixie pointed out in raising the
conflict between HTML5 and ES1-3 (and now ES5).
Just wanted to reassure you, since you seemed to think otherwise, that
no one views it as a feature that ES specs don't specify enough. HTML4
specs didn't either. We're getting there.
On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich <brendan at 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 <brendan at 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 sub-thread where I didn't see a message from you.
So confusing! So many messages!
No, you just replied off-topic and rehashed an issue that we all agree needs fixing, seemingly as if I had implied that it wasn't an issue. Although the generous citations of my reply to Doug Schepers that you included of course implied nothing of the kind.
Why did you do that?
I failed? There are about 100 messages on this topic that I'm reading and trying to digest. There's a whole lot of history involved. In the end, I can only speak for myself, and I can say that I'm personally having a lot of trouble trying to piece things together by looking at the specifications.
[big snip]
My point is that understanding the semantics of the language as implemented by browser vendors is not possible by reading the language spec. These is not some hypothetical extension, but a mandatory way that ECMAScript implemented for the web must behave.
Well, duh.
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 The whole point of bothering the HTML WG, public-webapps, and es-discuss about collaboration between Ecma and W3C folks has been to fill gaps between specs and reality. We had some false starts in my view (like trying to move ES WebIDL bindings to Ecma up front, or ever). But the issues laid out in Sam's original cross-post were exactly the "gaps" between ES specs, HTML5 ones, and browser implementations. At last some of the gaps are filled in HTML5 but not in ways that can be injected directly into ES specs.
I'm actually being a bit more radical than you are (perhaps naïvely). I am personally finding WebIDL to be a blocker to understanding. That's because it's another spec that interacts with two other (fairly complex) specs in unpredictable and context-sensitive ways.
We should fix the ES specs, and make whatever changes follow to the HTML5 specs. And maybe use WebIDL to constrain "host objects". All this has been said on the thread already. Were you not reading the messages I was?
I think I saw that in the thread ;)
Like I said, my problem is that the interaction between the three specs is making it nearly impossible for a casual reader to understand what's going on. I strongly apologize for not being clearer about that; I'm only starting to fully understand the source of my own confusion.
-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss- bounces at 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 additional, un-speced, behavior that isn't in ES that is necessary in order to construct a browser's DOM.
Consider the following scenario: I write an ECMAScript engine that is significantly faster than any existing engine by simply following the ECMAScript spec. A browser maker then wishes to use this engine. This would be impossible without adding additional (hidden) features to the engine to support the DOM. There is nothing in the ECMAScript spec that requires the ability (at the very least) to add native extensions with arbitrary behavior to the engine.
Is this a requirement ECMA is comfortable with?
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 defines an extended ECMAScrpt language with new semantics. (and I understand this is mostly a reflection of past (present?) practice of browser implementers). Essentially, the semantics of "browser ECMAScript" has been arbitrarily split into two independently maintained standards.
Language design is not primarily about designing individual isolated features. The hard parts of language design involves the interactions among such features and typically requires making design trade-offs and alteration to ensure that all features compose coherently.
If the language specification responsibilities are arbitrarily broken into two uncoordinated activities then it is impossible for either to do the global design that is necessary to have a complete and sound language and specification.
TC39 has the language design expertise. W3C has Web API design expertise. If there are language design issues that must be addressed in order to fully specify "browser ECMAScript" (and there are) then those issues need to be addressed by TC39. Perhaps TC309 has been remiss in the past in addressing these browser specific language design issues. If so, it was probably for historic political and competitive reasons that don't necessarily apply today. That is what we want to fix.
Allen Wirfs-Brock Microsoft
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 thSorry, rogue cut before send. "it's a bug in ES specs that you can't
follow them in order to implement a web-compatible JS engine."Although some of "web-compatible JS" really does belong in W3C
specs, not ES specs, it's clear ES1 pretending there is only one
global object did no one any favors. Ditto for execution model and
(ultimately) split windows, as Hixie pointed out in raising the
conflict between HTML5 and ES1-3 (and now ES5).Just wanted to reassure you, since you seemed to think otherwise,
that no one views it as a feature that ES specs don't specify
enough. HTML4 specs didn't either. We're getting there.
That's right. ES3, HTML4 and DOM Level 2 were all missing many things
needed to implement Web-compatible behavior, as well as having
requirements that were in some cases contrary to real-world
compatibility. Writing a new browser engine based on those specs
required multiple years of trial and error and reverse engineering
after implementing the spec behavior. Take it from me - that's what we
had to do to make WebKit (even building on the foundation of KHTML
+KJS, which had already done some of the reverse engineering).
ES5, HTML5, Web IDL and some of the Web Apps specs (like
XMLHttpRequest and DOM3 Events) are huge steps forward on this front.
They don't solve every problem, but they are massive improvements in
getting the Web platform correctly specified.
, Maciej
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 defines an extended ECMAScrpt
language with new semantics. (and I understand this is mostly a reflection of past (present?) practice of browser implementers). 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 access
catchalls?
, Maciej
From: Maciej Stachowiak [mailto:mjs at 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 access catchalls?
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 deficiencies in the language that should be addressed.
In particular now that ES5 is finished, WebIDL has a richer language to bind to then it had with ES3. We need a WebIDL binding that maximizes use of ES5 capabilities rather than inventing non-standard (from an ES perspective) language extensions.
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 deficiencies in the language that should be addressed.
In particular now that ES5 is finished, WebIDL has a richer language to bind to then it had with ES3. We need a WebIDL binding that maximizes use of ES5 capabilities rather than inventing non-standard (from an ES perspective) language extensions.
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 track?
On Sat, Sep 26, 2009 at 3:36 PM, Cameron McCormack <cam at 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 specs depending on it want to advance along the Rec track?
Since ES5 will be officially done well ahead of HTML5, I don't see why not. But I do not know what your "Rec track" constraints imply.
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 understand if these
special cases are exemplars of general deficiencies in the language that should be
addressed.In particular now that ES5 is finished, WebIDL has a richer
language to bind to then it had with ES3. We need a WebIDL binding that maximizes use of
ES5 capabilities rather than inventing non-standard (from an ES perspective) language
extensions.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 track?
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.
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 track?
Mark S. Miller:
Since ES5 will be officially done well ahead of HTML5, I don't see why not. But I do not know what your "Rec track" constraints imply.
For example, Selectors API is at Last Call and will soon be in Candidate Recommendation. I don’t think it can progress further than that until its dependencies move forward.
On Sat, Sep 26, 2009 at 3:48 PM, Oliver Hunt <oliver at 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 Oliver, it is precisely the need to clarify this interaction, as you pointed out in some of your previous posts to es-discuss, that got us to focus on the need for greater coordination at the last EcmaScript meeting. Since, as you say, this interaction is currently unclear, isn't this exactly the kind of problem our standards bodies should be trying to resolve?
On Sep 26, 2009, at 3:13 PM, Allen Wirfs-Brock wrote:
From: Maciej Stachowiak [mailto:mjs at 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
access catchalls?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 deficiencies in the language that should be
addressed.
We have definitely identified catchall property access as such an
area. Are there in fact any others? It's a lot more interesting to
look at specific examples than to expound on the general principles.
See below where I did some study to find other missing capabilities.
In particular now that ES5 is finished, WebIDL has a richer
language to bind to then it had with ES3. We need a WebIDL binding that maximizes use of ES5
capabilities rather than inventing non-standard (from an ES perspective) language
extensions.
Updating WebIDL to use ES5 concepts would definitely be worthwhile. At
the time Web IDL was started (early 2007 I think) this wasn't a
practical option, but it is now. In particular, interfaces that don't
have any unusual behavior could be defined as having getters and
setters, and should not need to override internal properties at all.
This would better highlight the capabilities that are needed to
implement the Web platform, but which can't be expressed in the
property descriptor formalism.
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.
From a quick scan of WebIDL, I see the following:
- Catchall getters, putters, deleters, definer.
- Variants that can make the catchall check happen either before
or after normal property lookup. - General string-based name access and index-only versions.
- Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.
- Variants that can make the catchall check happen either before
- Ability to support being called (via [[Call]]) without being a
Function. - Ability to support being invoked a constructor (via [[Construct]])
without being a Function. - Ability to support instanceof checking (via [[HasInstance]])
without being a constructor (so myElement instanceof HTMLElement works). - Ability to have [[Construct]] do something different than [[Call]]
instead of treating it as a [[Call]] with a freshly allocated Object
passed as "this".
Tentatively, I think all other semantics of Web IDL interfaces can be
implemented in pure ES5.
, Maciej
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 binding -- for instance using get or set properties on a dom
binding would require getOwnPropertyDescriptor to expose that
implementation detail.
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 specs depending on it want to advance along the Rec track?Mark S. Miller:
Since ES5 will be officially done well ahead of HTML5, I don't see
why not. But I do not know what your "Rec track" constraints imply.For example, Selectors API is at Last Call and will soon be in
Candidate Recommendation. I don’t think it can progress further than that until its dependencies move forward.
Selectors can't progress to PR/REC until Web IDL is in at least CR
state (only one difference in maturity level is allowed for
dependencies). I think Web IDL can enter CR with ES5 as is, but it
will be considered final as soon as it is published, which is likely
to be before Web IDL is ready for Last Call. ECMA process does not
have any states between the equivalent of W3C Working Draft and W3C
REC (as far as I know). So I don't think this would create any
problems for Selectors advancing, other than the time to do the rewrite.
On the substantive issue: I do think it would be good to convert Web
IDL from ES3 formalisms to ES5 formalisms. While Oliver is right that
ES5 has not yet been proven by interoperable implementations, and that
some of its methods as defined have a hard time with host objects, I
believe that the basic designs of ES5 property descriptors and ES5
getters/setters are sound.
, Maciej
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
help make this interaction more clear.
There are additional concerns -- various es5 features expose the
underlying implementation mechanisms of the binding -- for instance
using get or set properties on a dom binding would require
getOwnPropertyDescriptor to expose that implementation detail.
getOwnPropertyDescriptor risks leaking implementation details (or at
least implementation differences) in any case. The options for Web IDL
are:
- Leave the results of getOwnPropertyDescriptor completely
implementation-defined, so different implementations may return
different values. - Require getOwnPropertyDescriptor to return specific results that
expose host object properties as something other than getters or
setters. - Require getOwnPropertyDescriptor to return specific results that
expose host object properties as getters/setters.
I reluctantly conclude that #3 is best. #1 leaves behavior
unspecified, this needlessly creates the potential for interop
problems. #2 conflicts with the way some implementations implement
their DOM bindings (e.g. Gecko), meaning extra work for them, and is
outright unimplementable in pure ECMAScript. #3 conflicts with the way
some implementations implement their DOM bindings (e.g. WebKit) and
would mean extra work for them.
.#3 seems like it has the weakest disadvantages, even though it means
extra work for us.
However, if we want to allow implementation variance (i.e. policy #1),
we could still use ES5 getters and setters as the formal model, but
say that host objects implementations may override [[GetOwnProperty]]
to give implementation-defined results for host attributes. This would
change Web IDL from saying that host object implementations MUST
override internal methods to saying they MAY.
Regard, Maciej
-----Original Message----- From: Maciej Stachowiak [mailto:mjs at 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 language design in that all new language features must integrate with existing features. Combinatory feature interactions is one of the larger challenges of language design.
From a quick scan of WebIDL, I see the following:
- Catchall getters, putters, deleters, definer.
- Variants that can make the catchall check happen either before or after normal property lookup.
- General string-based name access and index-only versions.
No comment, I need to come up to speed on the detailed semantic requirements
- 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.
- Ability to support being called (via [[Call]]) without being a Function.
Not an issue with the core ES5 semantics. Most ES3/5 section 15 functions have this characteristic. As long as such WebIDL objects are defined similarly to the "built-in" function they too can have this characteristic. It may well be useful to introduce a mechanism defining such "pure" functions in the language but it probably isn't necessary to proceed with the WebIDL binding. The important thing to try to avoid is specify a custom [[Call]]
- Ability to support being invoked a constructor (via [[Construct]]) without being a Function.
Essentially same as 2 although the standard [[Construct]] requires a [[Call]] so this may need some more thought.
- Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement works).
Possibly the specification of the instanceof operator needs to be made extensible
- Ability to have [[Construct]] do something different than [[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as "this".
Similar to 4 regarding extensibility. At least one recent "harmony" strawman proposal is moving in a direction that may be relevent to 4 and 5. See strawman:obj_initialiser_constructors
On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote:
-----Original Message----- From: Maciej Stachowiak [mailto:mjs at 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 language design in that all new language features must integrate with existing features. Combinatory feature interactions is one of the larger challenges of language design.
From a quick scan of WebIDL, I see the following:
- Catchall getters, putters, deleters, definer.
- Variants that can make the catchall check happen either before or after normal property lookup.
- General string-based name access and index-only versions. No comment, I need to come up to speed on the detailed semantic
requirements
They are pretty similar to the way Array overrides
[[DefineOwnProperty]] or the way String defines
- 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 argued for removing the need for catchall deleters from
the Web Storage API (since nothing else requires , but other browser
vendors (including Mozilla) were happy with it, and I think now
everyone (including I believe Microsoft) has implemented the spec
behavior. See prior discussion thread here: <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html
. At this point, since we have multiple deployed implementations of
Web Storage, we'd have to investigate whether it's safe to remove this
behavior without breaking content.
- Ability to support being called (via [[Call]]) without being a Function.
Not an issue with the core ES5 semantics. Most ES3/5 section 15
functions have this characteristic. As long as such WebIDL objects are defined similarly
to the "built-in" function they too can have this characteristic. It may well be
useful to introduce a mechanism defining such "pure" functions in the language but it
probably isn't necessary to proceed with the WebIDL binding. The important thing to try to
avoid is specify a custom [[Call]]
I tend to agree that this behavior (and the next 3) are not
philosophically problematic, even though they cannot today be
implemented in pure ECMAScript.
- Ability to support being invoked a constructor (via [[Construct]]) without being a Function.
Essentially same as 2 although the standard [[Construct]] requires a
[[Call]] so this may need some more thought.
- Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement
works).Possibly the specification of the instanceof operator needs to be
made extensible
- Ability to have [[Construct]] do something different than [[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as "this".
Similar to 4 regarding extensibility. At least one recent "harmony"
strawman proposal is moving in a direction that may be relevent to 4 and 5. See strawman:obj_initialiser_constructors
Interesting. 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]] and [[Construct]]
that both exist but with different behavior.
, Maciej
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 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 be different from the Object [[Delete]] or the Array one seemed fine to me.
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 argued for removing the need for catchall deleters from
the Web Storage API (since nothing else requires , but other browser
vendors (including Mozilla) were happy with it,
"(including Mozilla)" and "happy with it" leave out some nuance:
lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014856.html
Robert O'Callahan here wrote "If overloading "delete" is too quirky or
too hard to implement, then it seems none of the other shorthands
should be allowed either." His message adverted to the better course
of methodical access instead of property access to Web Storage keyed
values.
Alas Rob finally gave up at:
lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014868.html
I think the Web Storage key/value reflection as properties is a
mistake. Sorry I wasn't reviewing it in time to say so. But it was
obviously not a situation everyone was "happy" with, even ignoring the
issue of delete.
and I think now everyone (including I believe Microsoft) has
implemented the spec behavior. See prior discussion thread here: <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html. At this point, since we have multiple deployed implementations
of Web Storage, we'd have to investigate whether it's safe to remove
this behavior without breaking content.
We could try to remove it -- or (what is more likely to go down
easily) we could add methods and let the property reflections wither,
and vow to avoid repeating this mistake.
- Ability to support being called (via [[Call]]) without being a Function.
Not an issue with the core ES5 semantics. Most ES3/5 section 15
functions have this characteristic. As long as such WebIDL objects are defined
similarly to the "built-in" function they too can have this characteristic. It may well be
useful to introduce a mechanism defining such "pure" functions in the language but it
probably isn't necessary to proceed with the WebIDL binding. The important thing to try to
avoid is specify a custom [[Call]]I tend to agree that this behavior (and the next 3) are not
philosophically problematic, even though they cannot today be
implemented in pure ECMAScript.
What does typeof say for such a callable object?
In what sense are any DOM methods required to be not Functions (native
function objects) in the specs? In Netscape of old and Mozilla
browsers since 1998, DOM methods are native function objects.
This seems winning since developers want not only sane typeof,
but .apply/call/bind.
We've talked on es-discuss about "pure" functions (ones without
[[Construct]] and .prototype) before:
mail.mozilla.org/pipermail/es5-discuss/2009-July/002920.html
in case you missed the thread. Agreed it's not a big deal. We have a
bugzilla.mozilla.org bug on file to fix our built-in functions (Date
methods, etc.) to lose [[Construct]] and .prototype. I'm not sure of
v8's plans.
First-class syntax for defining such non-constructor functions is
elusive. ;-)
- Ability to support being invoked a constructor (via
[[Construct]]) without being a Function.Essentially same as 2 although the standard [[Construct]] requires
a [[Call]] so this may need some more thought.
Is there anything specified via WebIDL that must be a constructor but
not a callable?
Ye olde Image and Option, at least, act like most built-in
constructors by constructing when called, at least in Gecko and I
think IE -- but not in WebKit (I just tested).
- Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement
works).Possibly the specification of the instanceof operator needs to be
made extensible
Definitely.
- Ability to have [[Construct]] do something different than
[[Call]] instead of treating it as a [[Call]] with a freshly allocated Object passed as "this".Similar to 4 regarding extensibility. At least one recent
"harmony" strawman proposal is moving in a direction that may be relevent to 4 and 5. See strawman:obj_initialiser_constructorsInteresting.
As an aside, the strawman for 'constructor' makes at least Mark Miller
and me want to unify 'class' and 'constructor' -- we don't want both,
and Harmony needs something already called class for several reasons,
one of them to model built-ins in ES1-5.
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]] and [[Construct]] that both exist but
with different behavior.
Date needs the latter.
-----Original Message----- From: Cameron McCormack [mailto:cam at 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 be different from the Object [[Delete]] or the Array one seemed fine to me.
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 if some edition of the ES specification chooses to adopt a different specification technique (which has been discussed).
Another issue with using specification internal methods as if they were an extension mechanism is that the ECMAScript specifications doesn't define any abstract contracts for them. What are the invariants that every [[Delete]] methods must maintain in order for the entire language to remain sound? It isn't currently defined. Within the ES spec. this isn't a big problem because most of the internal methods only have one definition within the ES specification and if there are more than one they have been designed with a unified semantics in mind.
Why is functionality that isn't available through native objects needed? If it is possible to define Java bindings for WebIDL that don't require extending the Java language why isn't it possible to approach JavaScript in the same manner (for new APIs, I understand the legacy issues).
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 if some edition of the ES specification chooses to adopt a different specification technique (which has been discussed).
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 IDL prescribes.
Another issue with using specification internal methods as if they were an extension mechanism is that the ECMAScript specifications doesn't define any abstract contracts for them. What are the invariants that every [[Delete]] methods must maintain in order for the entire language to remain sound? It isn't currently defined.
Or, defined to be “you can do anything”. Which admittedly isn’t useful if you are indeed trying to maintain some invariants.
Within the ES spec. this isn't a big problem because most of the internal methods only have one definition within the ES specification and if there are more than one they have been designed with a unified semantics in mind.
Why is functionality that isn't available through native objects needed?
For web compatibility, really.
If it is possible to define Java bindings for WebIDL that don't require extending the Java language why isn't it possible to approach JavaScript in the same manner (for new APIs, I understand the legacy issues).
Java really doesn’t have those compatibility issues.
Ignoring the legacy issues, assuming we have ES5 to build on, then yeah it seems like most things can be done (from Maciej’s quick analysis). The array like objects do seem like a useful pattern for authors to use, though.
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 IDL prescribes.
That is regrettable ES1-era language, written to accommodate the "host
objects" found prominently in IE due to too-low-level COM integration.
It should have come with color commentary advising against exploiting
the barn-door-sized loopholes.
Why is functionality that isn't available through native objects needed?
For web compatibility, really.
Web Storage is a recent example of something other than web
compatibility at work. Imitation of what went before, keystroke-
optimization to use the short property reference expression instead of
get/put/remove methods, or both, AFAICT.
Ignoring the legacy issues, assuming we have ES5 to build on, then
yeah it seems like most things can be done (from Maciej’s quick analysis). The array like objects do seem like a useful pattern for authors to
use, though.
Seems like everyone agrees Array-likes are not the issue.
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 for a new ES language extension.I previously argued for removing the need for catchall deleters
from the Web Storage API (since nothing else requires , but other
browser vendors (including Mozilla) were happy with it,"(including Mozilla)" and "happy with it" leave out some nuance:
lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014856.html
Robert O'Callahan here wrote "If overloading "delete" is too quirky
or too hard to implement, then it seems none of the other shorthands
should be allowed either." His message adverted to the better course
of methodical access instead of property access to Web Storage keyed
values.Alas Rob finally gave up at:
lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014868.html
I think the Web Storage key/value reflection as properties is a
mistake. Sorry I wasn't reviewing it in time to say so. But it was
obviously not a situation everyone was "happy" with, even ignoring
the issue of delete.
I accept your corrections as to nuance. At the time I felt like I was
fighting a losing battle. The real issue, though, is what to do going
forward.
and I think now everyone (including I believe Microsoft) has
implemented the spec behavior. See prior discussion thread here: <lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html. At this point, since we have multiple deployed implementations
of Web Storage, we'd have to investigate whether it's safe to
remove this behavior without breaking content.We could try to remove it -- or (what is more likely to go down
easily) we could add methods and let the property reflections
wither, and vow to avoid repeating this mistake.
There are methods, but I'm not optimistic that they will cause
property reflection to wither.
If the number of places in the Web platform that require custom delete
behavior goes from 1 to 2, that's a lot less bad than going from 0 to
- So it won't accomplish much. However, I missed a spot and it looks
like custom deleters are also used by the DOMStringMap interface,
which is used to reflect data-* attributes. <dev.w3.org/html5/spec/Overview.html#domstringmap-0
I don't think anyone has implemented that yet.
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 spec would follow suit.
I don't think I can convince my colleagues to remove the behavior from
WebKit if Gecko and Trident continue to support it.
- Ability to support being called (via [[Call]]) without being a Function.
Not an issue with the core ES5 semantics. Most ES3/5 section 15
functions have this characteristic. As long as such WebIDL objects are defined
similarly to the "built-in" function they too can have this characteristic. It may well be
useful to introduce a mechanism defining such "pure" functions in the language but it
probably isn't necessary to proceed with the WebIDL binding. The important thing to try to
avoid is specify a custom [[Call]]I tend to agree that this behavior (and the next 3) are not
philosophically problematic, even though they cannot today be
implemented in pure ECMAScript.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.
In what sense are any DOM methods required to be not Functions
(native function objects) in the specs? In Netscape of old and
Mozilla browsers since 1998, DOM methods are native function objects.
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. Constructors
like XMLHttpRequest, Option and Image also do not inherit from
Function.prototype even though they are callable.
This seems winning since developers want not only sane typeof,
but .apply/call/bind.
It's definitely winning, and it may be possible to apply it to global
constructors that are also callable as a future improvement, but it's
probably not possible to make HTMLCollection or HTMLFormElement
inherit from the Function prototype, and I think it would not be
desirable either.
We've talked on es-discuss about "pure" functions (ones without
[[Construct]] and .prototype) before:mail.mozilla.org/pipermail/es5-discuss/2009-July/002920.html
in case you missed the thread. Agreed it's not a big deal. We have a
bugzilla.mozilla.org bug on file to fix our built-in functions (Date
methods, etc.) to lose [[Construct]] and .prototype. I'm not sure of
v8's plans.First-class syntax for defining such non-constructor functions is
elusive. ;-)
This reminds me that I forgot to specifically call out the ability to
have a function that implements [[Calll]] but not [[Construct]]
(assuming that's not subsumed in giving them the ability to be
different).
Perhaps it's sufficient to provide an API for altering the [[Call]]
and [[Construct]] behavior of an existing object without a first-class
syntax, following in the spirit of defineOwnProperty(). Something like
foo.defineOperation("construct", funcToCallWhenConstructing). This
would address all of points 2 to 5, for ECMAScript implementations
that wish to precisely replicate DOM behavior. This approach could
also be used for index getters/setters/has-testers, general catchall
getters/setters/has-testers, removing either one of call or construct
while retaining the other, making call and construct do different
things, and perhaps other useses. And using a method instead of first-
class syntax would let scripts feature-test for this capability.
- Ability to support being invoked a constructor (via
[[Construct]]) without being a Function.Essentially same as 2 although the standard [[Construct]] requires
a [[Call]] so this may need some more thought.Is there anything specified via WebIDL that must be a constructor
but not a callable?
I did not specify "without being callable", just without inheriting
from Function. Currently, Image, Option and XMLHttpRequest are
examples of interfaces that make use of this point #3. They do not
have .apply or .call methods in any browser.
Ye olde Image and Option, at least, act like most built-in
constructors by constructing when called, at least in Gecko and I
think IE -- but not in WebKit (I just tested).
My testing seems to indicate not in IE. Likewise for XMLHttpRequest.
We should probably specify one way or the other whether these are
callable and stick to it. I am indifferent as to which behavior we
standardize on.
- Ability to support instanceof checking (via [[HasInstance]]) without being a constructor (so myElement instanceof HTMLElement
works).Possibly the specification of the instanceof operator needs to be
made extensibleDefinitely.
- Ability to have [[Construct]] do something different than
[[Call]] instead of treating it as a [[Call]] with a freshly allocated
Object passed as "this".Similar to 4 regarding extensibility. At least one recent
"harmony" strawman proposal is moving in a direction that may be relevent to 4 and 5. See strawman:obj_initialiser_constructorsInteresting.
As an aside, the strawman for 'constructor' makes at least Mark
Miller and me want to unify 'class' and 'constructor' -- we don't
want both, and Harmony needs something already called class for
several reasons, one of them to model built-ins in ES1-5.
Sounds reasonable, as long as this is flexible enough to implement the
behavior needed.
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]] and [[Construct]] that both exist but
with different behavior.Date needs the latter.
As do String, Number, Boolean and RegExp, if I recall correctly.
, Maciej
On Sep 26, 2009, at 10:55 PM, Allen Wirfs-Brock wrote:
-----Original Message----- From: Cameron McCormack [mailto:cam at 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 be different from the Object [[Delete]] or the Array one
seemed fine to me.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 if some edition of the ES
specification chooses to adopt a different specification technique (which has been
discussed).
ES5 seems to imply internal methods are an extension hook by using
them as such for a few built-in types, and by explicitly mentioning
they may behave arbitrarily differently for host objects. ES3 gave
this impression as well. While TC-39 seems to feel differently now, it
was very easy to get the impression by reading the spec that they are
indeed an extension hook. Beyond that, there doesn't seem to be any
other good way to soundly specify the behavior of a host object.
Another issue with using specification internal methods as if they
were an extension mechanism is that the ECMAScript specifications doesn't define any
abstract contracts for them. What are the invariants that every [[Delete]] methods
must maintain in order for the entire language to remain sound? It isn't currently
defined. Within the ES spec. this isn't a big problem because most of the internal methods only
have one definition within the ES specification and if there are more than one they have
been designed with a unified semantics in mind.Why is functionality that isn't available through native objects
needed? If it is possible to define Java bindings for WebIDL that don't require extending the
Java language why isn't it possible to approach JavaScript in the same manner (for new APIs,
I understand the legacy issues).
A) For Web compatibility of pre-existing APIs.
B) In the case of some behaviors already used by pre-existing APIs,
it's useful for new APIs to behave the same way. Some examples: array-
style index access, and traditional details of call and construct
behavior. It would be confusing if every new DOM method behaved
differently from all previous DOM method, or indeed differently from
ECMAScript built-in methods. It would be confusing if all new DOM
constructors were Functions, but old ones aren't. ECMAScript built-in
objects themselves make use some techniques cannot be implemented in
pure ECMAScript, so it seems off-base to me to criticize DOM APIs for
doing the same thing.
[[Delete]] is a different kettle of fish, since overriding its
behavior was not done by either ECMAScript built-ins or any legacy
APIs. But keep in mind, most of the things we're talking about are
already done by Array instances, String objects, built-in
constructors, or built-in methods.
, Maciej
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 is named 'key', heh).
Agreed it looks nearly hopeless to herd developers toward always using
these methods instead of .myKey, etc.
If the number of places in the Web platform that require custom
delete behavior goes from 1 to 2, that's a lot less bad than going
from 0 to 1. So it won't accomplish much. However, I missed a spot
and it looks like custom deleters are also used by the DOMStringMap
interface, which is used to reflect data-* attributes. <dev.w3.org/html5/spec/Overview.html#domstringmap-0I don't think anyone has implemented that yet.
Horses still out the barn door and we didn't close it yet, I'm not
sure who to blame except "us" (would be barn-door closers, possibly in
charge of those horses -- but perhaps they're not even ours!).
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 spec
would follow suit. I don't think I can convince my colleagues to
remove the behavior from WebKit if Gecko and Trident continue to
support it.
I'll see what the relevant Mozilla WebAPI hackers think, if they're
not reading this thread. At this point I suspect it is "too late", in
the sense that we'd be taking risks with plaform compatibility we
don't accept in our release version/compatibility plan.
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 choose "function" or "object" or any old string
("Implementation-dependent").
ES5 says:
Object (native or host and does implement [[Call]]) -> "function"
Object (host and does not implement [[Call]])
-> Implementation-defined except may not be "undefined", "boolean",
"number", or "string".
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. Constructors
like XMLHttpRequest, Option and Image also do not inherit from
Function.prototype even though they are callable.
Right, thanks for clarifying that. DOM collection types, even if
callable (VBScript was to blame) are not function objects, and DOM
constructors, unlike chapter 15 built-in ES constructors, are not
generally function objects.
This seems winning since developers want not only sane typeof,
but .apply/call/bind.It's definitely winning, and it may be possible to apply it to
global constructors that are also callable as a future improvement,
but it's probably not possible to make HTMLCollection or
HTMLFormElement inherit from the Function prototype, and I think it
would not be desirable either.
Why not for HTMLFormElement? Agree for HTMLCollection.
Perhaps it's sufficient to provide an API for altering the [[Call]]
and [[Construct]] behavior of an existing object without a first- class syntax, following in the spirit of defineOwnProperty().
Something like foo.defineOperation("construct",
funcToCallWhenConstructing). This would address all of points 2 to
5, for ECMAScript implementations that wish to precisely replicate
DOM behavior. This approach could also be used for index getters/ setters/has-testers, general catchall getters/setters/has-testers,
removing either one of call or construct while retaining the other,
making call and construct do different things, and perhaps other
useses. And using a method instead of first-class syntax would let
scripts feature-test for this capability.
See strawman:catchalls but note
objections there, as well as some alternatives discussed in es-discuss at mozilla.org
.
A MOP for catchalls that stratifies the hooks into mirage (by analogy
to mirror-based reflection) objects may be forthcoming; we'll see
(I'll let the experts say more). A dark horse, at this point, but hey,
those other horses made it out of the barn ;-).
For simple things like non-constructor functions one might prefer a
declarative form. As an implementor and a developer, I would --
mutation is a bitch to optimize in a VM, and to contain in one's "user
code". Also the meta-programming API seems likely to be more verbose
than the (still elusive, but stipulate that it must be concise)
hypothetical declarative syntax.
Ye olde Image and Option, at least, act like most built-in
constructors by constructing when called, at least in Gecko and I
think IE -- but not in WebKit (I just tested).My testing seems to indicate not in IE. Likewise for XMLHttpRequest.
We should probably specify one way or the other whether these are
callable and stick to it. I am indifferent as to which behavior we
standardize on.
Me too, except if I had to do it all over again I would have worked
harder to make function-ness orthogonal to prototype, a mixin if you
will. At this point,
takes away the need to inherit .apply/call, leaving bind as something
that might better be a primitive operator that works for all callables.
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 probably make less
progress than if we try to rationalize old and new in a better
systematic design.
So I too am indifferent so long as we do make progress factoring
function-ness out of which-prototype, if you get what I mean.
Date needs the latter.
As do String, Number, Boolean and RegExp, if I recall correctly.
Indeed. More warts to avoid generalizing into a complexion. :-/
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 choose "function" or "object" or any old
string ("Implementation-dependent").ES5 says:
Object (native or host and does implement [[Call]]) -> "function"
Object (host and does not implement [[Call]]) -> Implementation-defined except may not be "undefined", "boolean",
"number", or "string".
I think it may be a compatibility risk for HTMLCollection to report
its type as "function" instead of "object".
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.
Constructors like XMLHttpRequest, Option and Image also do not
inherit from Function.prototype even though they are callable.Right, thanks for clarifying that. DOM collection types, even if
callable (VBScript was to blame) are not function objects, and DOM
constructors, unlike chapter 15 built-in ES constructors, are not
generally function objects.This seems winning since developers want not only sane typeof,
but .apply/call/bind.It's definitely winning, and it may be possible to apply it to
global constructors that are also callable as a future improvement,
but it's probably not possible to make HTMLCollection or
HTMLFormElement inherit from the Function prototype, and I think it
would not be desirable either.Why not for HTMLFormElement? Agree for HTMLCollection.
By HTMLFormElement I mean the actual instances that represent the
<form> element in an HTML DOM, not the pseudo-constructor object named
"HTMLFormElement" on the window object. HTML5 gives it callable
indexing. It already inherits from HTMLElement (and Element and Node)
so it's unclear how to stick Function into its prototype chain. And I
don't think we want call(), apply() and bind() methods to start
appearing on form elements.
Perhaps it's sufficient to provide an API for altering the [[Call]]
and [[Construct]] behavior of an existing object without a first- class syntax, following in the spirit of defineOwnProperty().
Something like foo.defineOperation("construct",
funcToCallWhenConstructing). This would address all of points 2 to
5, for ECMAScript implementations that wish to precisely replicate
DOM behavior. This approach could also be used for index getters/ setters/has-testers, general catchall getters/setters/has-testers,
removing either one of call or construct while retaining the other,
making call and construct do different things, and perhaps other
useses. And using a method instead of first-class syntax would let
scripts feature-test for this capability.See strawman:catchalls but
note objections there, as well as some alternatives discussed in es-discuss at mozilla.org .
Thanks for the reference. That does look similar to my suggestion.
However, it looks like the "invoke" and "construct" methods there are
intended for calling a property of the object (or invoking it as a
constructor), rather than for applying call or construct to the object
itself.
A MOP for catchalls that stratifies the hooks into mirage (by
analogy to mirror-based reflection) objects may be forthcoming;
we'll see (I'll let the experts say more). A dark horse, at this
point, but hey, those other horses made it out of the barn ;-).For simple things like non-constructor functions one might prefer a
declarative form. As an implementor and a developer, I would --
mutation is a bitch to optimize in a VM, and to contain in one's
"user code". Also the meta-programming API seems likely to be more
verbose than the (still elusive, but stipulate that it must be
concise) hypothetical declarative syntax.
Sure - one way a MOP approach helps is by moving past debates about
the most elegant syntax, by having unapologetically inelegant syntax.
Then maybe once the capability is there, someone can invent good
syntax later.
Ye olde Image and Option, at least, act like most built-in
constructors by constructing when called, at least in Gecko and I
think IE -- but not in WebKit (I just tested).My testing seems to indicate not in IE. Likewise for
XMLHttpRequest. We should probably specify one way or the other
whether these are callable and stick to it. I am indifferent as to
which behavior we standardize on.Me too, except if I had to do it all over again I would have worked
harder to make function-ness orthogonal to prototype, a mixin if you
will.
I wish functions and constructors were different kinds of things. I'm
not sure if that's the same kind of idea you're talking about.
At this point,
takes away the need to inherit .apply/call, leaving bind as
something that might better be a primitive operator that works for
all callables.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 probably make less
progress than if we try to rationalize old and new in a better
systematic design.
That's a little too abstract for me to tell if I agree or not.
So I too am indifferent so long as we do make progress factoring
function-ness out of which-prototype, if you get what I mean.Date needs the latter.
As do String, Number, Boolean and RegExp, if I recall correctly.
Indeed. More warts to avoid generalizing into a complexion. :-/
It doesn't seem that crazy to me to have different call and construct
behavior, though the differences in these cases may be confusingly
subtle.
, Maciej
On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote:
See strawman:catchalls but
note objections there, as well as some alternatives discussed in es-discuss at mozilla.org .Thanks for the reference. That does look similar to my suggestion.
However, it looks like the "invoke" and "construct" methods there
are intended for calling a property of the object (or invoking it as
a constructor), rather than for applying call or construct to the
object itself.
The discussion (the thread started here:
) brought out this and other points. Having to reify an object as a
property value, only to invoke it somehow (call or construct), often
makes excess garbage, hence this proposal's call-property and
construct-property hooks.
But your point is good too: sometimes you already have an object and
it needs to act as a callable or constructor.
A mirage-based dark-horse candidate proposal will (I hope) deal with
both cases.
For simple things like non-constructor functions one might prefer a
declarative form. As an implementor and a developer, I would --
mutation is a bitch to optimize in a VM, and to contain in one's
"user code". Also the meta-programming API seems likely to be more
verbose than the (still elusive, but stipulate that it must be
concise) hypothetical declarative syntax.Sure - one way a MOP approach helps is by moving past debates about
the most elegant syntax, by having unapologetically inelegant
syntax. Then maybe once the capability is there, someone can invent
good syntax later.
Preferably before anything is prematurely standardized...
Me too, except if I had to do it all over again I would have worked
harder to make function-ness orthogonal to prototype, a mixin if
you will.I wish functions and constructors were different kinds of things.
I'm not sure if that's the same kind of idea you're talking about.
I said that at ICFP 2005 in answer to a question (from Simon Peyton- Jones, IIRC), so I agree.
But beyond separating functions from constructors, the ability to
spread array elements as positional actual parameters, and to deal
with |this|-binding separately for functions, help to untangle the
multiple strands of magic woven into function objects in ES so far.
Combining constructors and functions is not the only case of unwanted
entangling.
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 probably make less
progress than if we try to rationalize old and new in a better
systematic design.That's a little too abstract for me to tell if I agree or not.
Shortest-path evolution can walk uphill only a little bit at a time,
and get stuck at local minimal points in a design space, when over the
big hill is a much better, richer valley to evolve in. This path
dependency problem bits many real-world systems.
I experience this point as hard and painful, like concrete -- it' s
not abstract. I've been around too long to ignore it, as it's all
around us on the web, and it has been since 1994 if not earlier.
Compatibility concerns in the form of graceful degradation or
progressive enhancement are not unmixed blessings. More coherent
stacks from Microsoft, Adobe, and Sun can rightly claim to solve
problems more cleanly and simply than the web. Of course these stacks
have other problems, mainly from being single-sourced if not
proprietary, but also from not progressing compatibly, and for other
reasons I won't digress on.
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!
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 want to advance along the Rec track?
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 only because it is
familiar, which might point to building the ES5 one separately.
If at all possible I'd rather it went to LC ASAP, and if needed that
new stuff be done in a branched document.
On Sun, Sep 27, 2009 at 12:35 PM, Robin Berjon <robin at berjon.com> 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 ES3) at this point, given that specs depending on it want to advance along the Rec track?
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 only because it is familiar,
This seems like a standard without an audience, as ES5 is becoming official well ahead of HTML5. Who needs HTML5 on ES3?
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
probably make less progress than if we try to rationalize old and
new in a better systematic design.That's a little too abstract for me to tell if I agree or not.
Shortest-path evolution can walk uphill only a little bit at a time,
and get stuck at local minimal points in a design space, when over
the big hill is a much better, richer valley to evolve in. This path
dependency problem bits many real-world systems.I experience this point as hard and painful, like concrete -- it' s
not abstract. I've been around too long to ignore it, as it's all
around us on the web, and it has been since 1994 if not earlier.Compatibility concerns in the form of graceful degradation or
progressive enhancement are not unmixed blessings. More coherent
stacks from Microsoft, Adobe, and Sun can rightly claim to solve
problems more cleanly and simply than the web. Of course these
stacks have other problems, mainly from being single-sourced if not
proprietary, but also from not progressing compatibly, and for other
reasons I won't digress on.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 compatibility. So I'm not that
excited about the exciting opportunities we could have if we did. The
Web is a duct tape design but it works. Dropping compatibility would
kill one of its biggest advantages.
Systems that discard compatibility can also deliver an unusable Second
System, especially when designed by committee. I would point to
certain W3C specs that chose to break compatibility with existing
practice. They are often not only undeployable but also not very
compelling on their own terms.
I think compatibility constraints, even though they impose messy and
illogical quirks, can also act as a healthy counterweight to flights
of design fancy. Constraints make for good art.
, Maciej
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 ES3) at this point, given that specs depending on it want to advance along the Rec track?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 only because it is
familiar, which might point to building the ES5 one separately.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 state would not survive Last Call.
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 compatibility. So I'm not that
excited about the exciting opportunities we could have if we did.
The Web is a duct tape design but it works. Dropping compatibility
would kill one of its biggest advantages.
Sure. You didn't see me proposing dropping Web compatibility (suicide
for browser vendors) -- rather, I'm talking about doing end-to-end
design as we go, and meeting in the middle.
Too many short hops via a standard body incurs high costs in the spec
process (some essential, some not) while tending to enshrine mistakes
over time due to compatibility. Whereas taking big hops risks mission
creep, or mission cliff-dive into second-system death-beach ;-), or
even the old mistake of targeting a market foreseen five years out
that never arrives (the real world zigged instead of zagging).
We've all seen these problems, I think, over our careers. And it's not
as if the proprietary languages and stacks can break compatibility
excessively (search for "Visual Fred"). But they can and do provide
new and more coherent API-sets that help deprecate old ones.
To avoid proprietary stack examples, consider Python's from future
import mechanism:
www.python.org/dev/peps/pep-0236
This precedent is attractive if one can push out new versions of the
language implementation, with carrots to induce people to upgrade, as
well as the stick of unsupported ancient versions. It helps that C-
Python is source-as-spec, but let's say that is a non-issue with good-
enough ES specs.
The "carrots instead of sticks" idea is more critical from what I have
seen, for Python and for JavaScript -- we can't get people to stop
doing what worked if there's no new and better way (the recent
arguments.callee in strict mode thread highlighted this point).
Of course, the web is too big to try to get away with deprecation/
obsolescence cycles on any predictable near-term release schedule.
Never mind coordination among browser vendors on their next versions
-- IE6 is still Out There.
But perhaps once past IE6, though, with modern browsers auto-updating,
we'll see the downrev implementations go away faster. There's a
chance, anyway, from what I see of IE8 replacing IE7, and of course
faster updating for other, "fresher" browsers ;-).
If we do see a world where browser version uptake is faster, and the
downrev problem shrinks or becomes more tractable somehow, then we
will want shinier duct tape without bits of lint and trash stuck to
the edges of the tape roll, over time. Every compatibility constraint
costs non-linearly when refracted through the whole-language design
process.
So part of ECMAScript "Harmony" is not just "ES6", a prematurely-
triaged, shortest-path evolutionary jump, but longer-term "end to end"
design that ultimately puts the TC39 committee out of the language-
extension business by empowering developers to bootstrap new language
versions by themselves.
Systems that discard compatibility can also deliver an unusable
Second System, especially when designed by committee. I would point
to certain W3C specs that chose to break compatibility with existing
practice. They are often not only undeployable but also not very
compelling on their own terms.
Agreed.
I think compatibility constraints, even though they impose messy and
illogical quirks, can also act as a healthy counterweight to flights
of design fancy. Constraints make for good art.
We seem to have some unnecessary constraints, which are bad for art
and science. Let's try to get rid of the foo(i) for foo[i] or
foo.item[i] non-mandatory compatibility cruft and see how that goes.
On Sep 27, 2009, at 21:44 , Mark S. Miller wrote:
On Sun, Sep 27, 2009 at 12:35 PM, Robin Berjon <robin at 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 term at least) if only because it is
familiar,This seems like a standard without an audience, as ES5 is becoming
official well ahead of HTML5. Who needs HTML5 on ES3?
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 lot of these cannot move forward along the
process until WebIDL itself moves ahead.
Don't get me wrong, I'm not in the least hostile to an ES5 binding. I
just don't want to rush into it and have a knock-on effect on the
timeliness of a bunch of other people's work.
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 state would not survive Last Call.
Which is fine, being grilled through LC is progress. I would just like
to avoid piling up even more things that it needs to do.
On Mon, Sep 28, 2009 at 2:02 AM, Robin Berjon <robin at 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 WebIDL, a lot of these cannot move forward along the process until WebIDL itself moves ahead.
Don't get me wrong, I'm not in the least hostile to an ES5 binding. I just don't want to rush into it and have a knock-on effect on the timeliness of a bunch of other people's work.
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, other things are never equal. Why do these other projects need a new version of WebIDL?
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 so far, I expect Web IDL in roughly its
current state would not survive Last Call.Which is fine, being grilled through LC is progress. I would just
like to avoid piling up even more things that it needs to do.
We're supposed to do our best to address likely objections before Last
Call.
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 a branched document.Based on the conversation so far, I expect Web IDL in roughly its
current state would not survive Last Call.Which is fine, being grilled through LC is progress. I would just
like to avoid piling up even more things that it needs to do.We're supposed to do our best to address likely objections before
Last Call.
Hence the "AP" part of "ASAP".
On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote:
[much appreciated information snipped -- thanks!]
I alluded to employers who are not currently paying W3C members not
wanting their employees participating, even individually. I'll let one
notable example that I know of speak for himself.
The "mailing list as firehose" problem can be solved with enough work,
but with two standards groups there is always greater risk of
conflict, and just competition for attention. Two lists is simply one
more list than one list to keep up with.
This is a price of collaboration at wider scale, so don't let me stand
in the way, since I've been explicit about being in favor of
collaboration.
W3C and Ecma both have transparency issues, but I don't expect those
to be fixed easily. I mentioned them ("People in dark-glass houses ...
[should not throw stones]") in reply to Maciej asserting greater
openness on one side. Again this is not a "barrier" I'm trying to take
down right now.
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 one more > low-traffic mailing list. Are there other barriers you see? I alluded to employers who are not currently paying W3C members not wanting their employees participating, even individually. I'll let one notable example that I know of speak for himself. The "mailing list as firehose" problem can be solved with enough work, but with two standards groups there is always greater risk of conflict, and just competition for attention. Two lists is simply one more list than one list to keep up with. This is a price of collaboration at wider scale, so don't let me stand in the way, since I've been explicit about being in favor of collaboration. W3C and Ecma both have transparency issues, but I don't expect those to be fixed easily. I mentioned them ("People in dark-glass houses ... [should not throw stones]") in reply to Maciej asserting greater openness on one side. Again this is not a "barrier" I'm trying to take down right now. /be