Web IDL Garden Hose
Cameron McCormack wrote:
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.
That's why we need closer cooperation between TC39 and the standardizers of WebIDL in future. If TC39 had been consulted, the disapproval of using this mechanism in this way would have been expressed.
As Allen says, [[Delete]] and other internal properties are not intended as an extension mechanism for arbitrary use by API bindings to ECMAScript. Some internal methods, like [[Call]] and [[Construct]], are relatively safe to override, but for others the invariants that the ES spec depends on are quite delicate.
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure ECMAScript. The current proposal does allow [[Construct]] without [[Call]], but not [[Call]] and [[Construct]] that both exist but
with different behavior.Date needs the latter.
That can already be done in ES5. As I've previously suggested:
function Date(yearOrValue, month, date, hours, minutes, seconds,
ms) { "use strict"; if (this === undefined) { return TimeToString(CurrentTime()); } // constructor behaviour ... }
Of course, a variation on "the idiom".
This is similar to what many implementations do too, rather than the
implementation providing analogues of [[Call]] and [[Construct]]
internal method on a non-function Date object. It works for Boolean,
Number, String, and RegExp too.
But it is just a bit unsightly!
Resending per request at the bottom of Boris' email. Another example of why we need a joint list.
---------- Forwarded message ---------- From: Boris Zbarsky <bzbarsky at mit.edu>
Date: Sun, Sep 27, 2009 at 12:23 PM Subject: Re: Web IDL Garden Hose To: Brendan Eich <brendan at mozilla.com>
Cc: "public-webapps at w3.org" <public-webapps at w3.org>, HTML WG <
public-html at w3.org>, es-discuss <es-discuss at mozilla.org>
On 9/27/09 3:30 AM, Brendan Eich wrote:
I believe we could get rid of custom deleters from the Web platform if
Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for DOMStringMap. If that happened, I'm sure other browsers and the 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.
Well, that depends on what we mean by "remove". Probably not removable in Gecko 1.9.1.x security updates. Probably removable (in my opinion) in Gecko 1.9.3. Possibly in Gecko 1.9.2 if the decision is made soon.
What I don't have is data on how much the syntax is used, or how likely Trident is to remove it too. If we remove it and Trident doesn't and that means Webkit keeps shipping it and the spec doesn't change as a result (which sounds to me like what Maciej is saying will be the outcome in this situation; the spec part is my guess based on the .tags experience) then from our point of view it's just wasted effort and web developers being pissed off at us for not implementing The Spec (without understanding that it's an early draft) and then we'd end up just having to put deleters back in but lose a bunch of goodwill. That's a strictly losing proposition for us.
If Webkit commits to removing if we remove and the editor commits to removing from the spec in that circumstance, then I think we could make the removal stick no matter what Trident does...
-Boris
P.S. I am ccing es-discuss on this as on my other mails, but of course that list bounces all mail from me, since I'm not a member. If someone cares about letting that list's membership know that they're missing part of the discussion and is able to do so, please go for it.
Brendan Eich wrote:
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure ECMAScript. The current proposal does allow [[Construct]] without [[Call]], but not [[Call]] and [[Construct]] that both exist but with different behavior.
Date needs the latter.
That can already be done in ES5. As I've previously suggested:
function Date(yearOrValue, month, date, hours, minutes, seconds, ms) { "use strict"; if (this === undefined) { return TimeToString(CurrentTime()); } // constructor behaviour ... }
Of course, a variation on "the idiom".
This is similar to what many implementations do too, rather than the implementation providing analogues of [[Call]] and [[Construct]] internal method on a non-function Date object. It works for Boolean, Number, String, and RegExp too.
But it is just a bit unsightly!
<shrug>. It's compatibility guff. Unsightliness in implementation code
is better than adding a language mechanism just to handle a small and fixed (for all time, hopefully) set of special cases.
(This has probably drifted off-topic for public-{webapps,html}@w3.org, sorry about that.)
I added you to the sender whitelist, so you can post to es- discuss without being a member.
Your post at
lists.w3.org/Archives/Public/public-webapps/2009JulSep/1427.html
is good too, I'm linking it here for es-discuss's benefit.
In general the VBScript-inflicted foo(i) for foo[i] or foo.item[i]
syntax is a sore point with me, causing painful flashbacks to 1997. I
don't see why it should be in any W3C standard if it's not truly
required for web compat (as Gecko's lack of support for it implies).
On Sep 27, 2009, at 11:14 AM, Brendan Eich wrote:
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:
This may provide a way to implement some of these behaviors in pure ECMAScript. The current proposal does allow [[Construct]] without [[Call]], but not [[Call]] and [[Construct]] that both exist but
with different behavior.Date needs the latter.
That can already be done in ES5. As I've previously suggested:
function Date(yearOrValue, month, date, hours, minutes, seconds,
ms) { "use strict"; if (this === undefined) { return TimeToString(CurrentTime()); } // constructor behaviour ... }Of course, a variation on "the idiom".
This is similar to what many implementations do too, rather than the
implementation providing analogues of [[Call]] and [[Construct]]
internal method on a non-function Date object. It works for Boolean,
Number, String, and RegExp too.But it is just a bit unsightly!
Will this do the right thing if you explicitly bind Date to a "this"
value, for example, by calling it as window.Date(), or using call,
apply, or function.bind, or by storing Date as the property of another
random object?
, Maciej
On Sep 27, 2009, at 12:23 PM, Boris Zbarsky wrote:
On 9/27/09 3:30 AM, Brendan Eich wrote:
I believe we could get rid of custom deleters from the Web
platform if Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for
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.Well, that depends on what we mean by "remove". Probably not
removable in Gecko 1.9.1.x security updates. Probably removable (in
my opinion) in Gecko 1.9.3. Possibly in Gecko 1.9.2 if the decision
is made soon.What I don't have is data on how much the syntax is used, or how
likely Trident is to remove it too. If we remove it and Trident
doesn't and that means Webkit keeps shipping it and the spec doesn't
change as a result (which sounds to me like what Maciej is saying
will be the outcome in this situation; the spec part is my guess
based on the .tags experience) then from our point of view it's just
wasted effort and web developers being pissed off at us for not
implementing The Spec (without understanding that it's an early
draft) and then we'd end up just having to put deleters back in but
lose a bunch of goodwill. That's a strictly losing proposition for
us.If Webkit commits to removing if we remove and the editor commits to
removing from the spec in that circumstance, then I think we could
make the removal stick no matter what Trident does...
I could probably go along with that plan, if we are really motivated
to do this. It would be good to have Microsoft's input as well. I
would also find data about use of this syntax useful, if anyone has any.
P.S. I am ccing es-discuss on this as on my other mails, but of
course that list bounces all mail from me, since I'm not a member.
If someone cares about letting that list's membership know that
they're missing part of the discussion and is able to do so, please
go for it.
, Maciej
On Sep 27, 2009, at 12:37 PM, Boris Zbarsky wrote:
On 9/27/09 2:28 AM, Maciej Stachowiak wrote:
This is not an issue for DOM methods. It's an issue for interfaces
such as HTMLCollection and HTMLFormElement that support indexing by
function call syntax, for legacy compatibility reasons.Huh. Gecko hasn't supported this, and we haven't had problems with
it. Is it really for legacy compat reasons, of just because more
than one vendor happens to support it without really knowing why,
like tags() on HTMLCollection? Did Webkit and Opera have particular
compat issues without implementing this stuff?For what it's worth, I just tested and it looks like Opera and
Webkit support () on HTMLCollection; the former doesn't support it
on the return value of getElementsByTagName while the latter does.
Gecko does not support either. The spec also has the () thing going
on for HTMLFormControlsCollection; again we've never had any serious
compat problems with this in Gecko.As for HTMLFormElement, while the spec says what it says, it's not
exactly for "compatibility reasons" other than "IE must be willing
to implement this spec and nothing outside this spec", I assume.
Both Opera and Webkit throw in this testcase:<!DOCTYPE html> <body> <form name="foo"> <input name="bar"> <script>try { alert(document.foo("bar")); } catch(e) { alert(e); } </script>
whereas they should return the input, per spec.
I hadn't realizes the spec required this syntax, and I would be
somewhat interested in understanding why it does and whether it's
actually required "for compatibility reasons" (in the sense that a
new UA on the market would have to implement it to be compatible
with existing sites).
I wouldn't be against dropping things that we really think are
useless. Keep in mind though, there is still old content (yes, often
on Intranets, but sometimes publicly accessible) that just assumes IE,
but more or less works if you implement enough IE-isms. That's the
rationale behind undetectable document.all. Callable collections are
based on the same kind of reasoning. Historically, Opera and Safari
(and Konqueror/KHTML before us) have been somewhat more willing to
implement weird IE-isms than Mozilla.
, Maciej
On Mon, 28 Sep 2009 17:20:27 +0200, Mark S. Miller <erights at google.com>
wrote:
Good point. I was indeed thinking only of HTML5. Other things being
equal, it would seem the best way for these other projects to avoid
blocking on WebIDL would be for them to rely only on the previous version of WebIDL.
Of course, other things are never equal. Why do these other projects
need a new version of WebIDL?
There is no old version.
On Sep 28, 2009, at 17:23 , Anne van Kesteren wrote:
On Mon, 28 Sep 2009 17:20:27 +0200, Mark S. Miller
<erights at google.com> wrote:Good point. I was indeed thinking only of HTML5. Other things being
equal, it would seem the best way for these other projects to avoid
blocking on WebIDL would be for them to rely only on the previous version of
WebIDL. Of course, other things are never equal. Why do these other
projects need a new version of WebIDL?There is no old version.
Right, this is v1. What previous W3C API specifications had relied on
was either OMG IDL, or the common lore understanding that people were
familiar with this way of expressing APIs, so they'd get it right.
We're trying to do a bit better than that.
-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss- bounces at mozilla.org] On Behalf Of Robin Berjon
There is no old version.
Right, this is v1. What previous W3C API specifications had relied on was either OMG IDL, or the common lore understanding that people were familiar with this way of expressing APIs, so they'd get it right. We're trying to do a bit better than that.
The primary concern of TC39 members is with the WebIDL ECMAScript bindings. I haven't yet heard any particular concerns from TC9 about WebIDL as an abstract language independent interface specification language. Since W3C seems committed to defining language independent APIs, I would think that the language independent portion of the WebIDL spec. would be the only possible blocker to other new specs.
It seems like this might be a good reason to decouple the specification of the actual WebIDL language from the specification of any of its language bindings.
Allen Wirfs-Brock Microsoft
On Sep 28, 2009, at 10:12 AM, Allen Wirfs-Brock wrote:
-----Original Message----- From: es-discuss-bounces at mozilla.org [mailto:es-discuss- bounces at mozilla.org] On Behalf Of Robin Berjon
There is no old version.
Right, this is v1. What previous W3C API specifications had relied on was either OMG IDL, or the common lore understanding that people were familiar with this way of expressing APIs, so they'd get it right. We're trying to do a bit better than that.
The primary concern of TC39 members is with the WebIDL ECMAScript
bindings. I haven't yet heard any particular concerns from TC9
about WebIDL as an abstract language independent interface
specification language. Since W3C seems committed to defining
language independent APIs, I would think that the language
independent portion of the WebIDL spec. would be the only possible
blocker to other new specs.It seems like this might be a good reason to decouple the
specification of the actual WebIDL language from the specification
of any of its language bindings.
Defining the Web IDL syntax without defining any language bindings
would not be very useful:
-
The syntax is to a large extent designed around being able to
express the right behavior for language bindings, particularly
ECMAScript bindings. So we can't really lock it down without knowing
that it can express the needed behavior in the bindings, which
requires the bindings to be done. -
To actually implement any spec using Web IDL, implementors need at
least one language binding, and most implementors will consider an
ECMAScript binding to be essential. Without the bindings being
defined, it will not be possible to build sound test suites for the
specs using Web IDL. -
The whole point of Web IDL was to define how DOM and related Web
APIs map to languages, and especially ECMAScript. Previous specs used
OMG IDL where the mapping was not formally defined, and implementors
had to read between the lines. Removing language bindings from Web IDL
would return us to the same bad old state, thus missing the point of
doing Web IDL in the first place.
, Maciej
It would be pretty nice if the language bindings of WebIDL were available in pure ES, where possible. To some degree, that is not currently possible (in ES3), but it will be a lot better in ES5. I think it might actually be possible to get a large degree of completion just using the JavaScript available in Spidermonkey.
This might also be a useful step in the direction that I was hoping for in some earlier postings.
On Sep 28, 2009, at 11:34 PM, Yehuda Katz wrote:
It would be pretty nice if the language bindings of WebIDL were available in pure ES, where possible. To some degree, that is not currently possible (in ES3), but it will be a lot better in ES5. I think it might actually be possible to get a large degree of completion just using the JavaScript available in Spidermonkey.
What do you mean by "available"? A lot of Web IDL interfaces are
actually implementable in ES5 (at least the interface part - not
necessarily the underlying functionality without relying on APIs
outside the language). Using ES5 as the reference baseline would help
make this more clear perhaps.
I meant "actually written". Being able to see actual code that implemented pieces of the IDL in ES would make some of the more complex interactions more obvious (I suspect).
+public-script-coord -public-webapps
(Soon I will start dropping es-discuss too).
On Sep 29, 2009, at 3:38 AM, Yehuda Katz wrote:
I meant "actually written". Being able to see actual code that
implemented pieces of the IDL in ES would make some of the more
complex interactions more obvious (I suspect).
I don't entirely understand this request. The IDL just defines an
interface. ECMAScript doesn't have a way to declare an interface
without implementing it. And the actual behavior of most objects
described with Web IDL interfaces is not implementable in pure
ECMAScript - not the interface behavior, the actual core behavior. But
maybe you can help me understand what you want with an example. Here's
a trivial Web IDL interface, what would count as an ES implementation
to you:
interface FooBar { boolean isFoo(DOMString a, long b); boolean isBar(DOMString a, long b); }
, Maciej
-----Original Message----- From: Maciej Stachowiak [mailto:mjs at apple.com]
I don't entirely understand this request. The IDL just defines an interface. ECMAScript doesn't have a way to declare an interface without implementing it. And the actual behavior of most objects described with Web IDL interfaces is not implementable in pure ECMAScript - not the interface behavior, the actual core behavior. But maybe you can help me understand what you want with an example. Here's a trivial Web IDL interface, what would count as an ES implementation to you:
interface FooBar { boolean isFoo(DOMString a, long b); boolean isBar(DOMString a, long b); }
How about:
var ForBar = { /Interface/ // This object defines a WebIDL interface. Objects compatible with this interface // must implement all of the following properties in a manner that preserves the // pre and post conditions established by the following definitions isFoo: function (a,b) { var validated_a=WebIDL.toDOMString(a); var validated_b=WebIDL.toLong(b); var specifiedresult=WebIDL.performSpecifiedOperation("FooBar.isFoo"),validated_a,validated_b); return Boolean(specified_result); }, isBar: function (a,b) { var validated_a=WebIDL.toDOMString(a); var validated_b=WebIDL.toLong(b); var specified_result=WebIDL.performSpecifiedOperation("FooBar.isBar"),validated_a,validated_b); return Boolean(specified_result); } }
Brendan Eich wrote:
That can already be done in ES5. As I've previously suggested:
function Date(yearOrValue, month, date, hours, minutes, seconds, ms) { "use strict"; if (this === undefined) { return TimeToString(CurrentTime()); } // constructor behaviour ... }
Brendan Eich wrote: > On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote: > >> This may provide a way to implement some of these behaviors in pure >> ECMAScript. The current proposal does allow [[Construct]] without >> [[Call]], but not [[Call]] and [[Construct]] that both exist but with >> different behavior. > > Date needs the latter. That can already be done in ES5. As I've previously suggested: function Date(yearOrValue, month, date, hours, minutes, seconds, ms) { "use strict"; if (this === undefined) { return TimeToString(CurrentTime()); } // constructor behaviour ... } -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com