On Sep 25, 2009, at 2:38 AM, Sam Ruby wrote:
Maciej Stachowiak wrote:
On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
That sounds reasonable. There are really two issues. One is that
there are parts of WebIDL that are unused. Another is that the
parts of the spec themselves are fairly arcane and very
implementor-specific. Consider:
interface UndoManager {
readonly attribute unsigned long length;
getter any item(in unsigned long index);
readonly attribute unsigned long position;
unsigned long add(in any data, in DOMString title);
void remove(in unsigned long index);
void clearUndo();
void clearRedo();
};
I almost forget that I'm looking at something most widely
implemented in a dynamic language when I look at that. Since this
is most likely to be implemented in terms of ECMAScript, why not
provide an ECMAScript reference implementation?
These methods do things that can't actually be implemented in pure
ECMAScript, since they need to tie into the browser implementation
and system APIs. So a reference implementation in ECMAScript is not
possible.
I'll accept that it is a true statement that in an pure ECMAScript
implementation of these interfaces in Safari on Mac OSX such
wouldn't be possible.
Alternate perspective, one that I believe more closely matches the
view of TC39: one could image an operating system and browser
implemented in either in ECMAScript or in a secure subset thereof.
In such an environment it would be highly unfortunate if the the
WebIDL for something as important as HTML5 and WebApps were written
in such a way as to preclude the creation of a conforming ECMAScript
implementation.
Unfortunately, this is the case. But in many cases this is due to
legacy compatibility requirements combined with certain features that
do not (yet) exist in ECMAScript. See below.
At this point, I'm not personally interested in discussions as to
whether WebIDL is or is not the right way forward. Anybody who
wishes to invest their time in producing more useful documentation
and/or reference implementations is not only welcome to do so, they
are positively encouraged to do so.
Meanwhile, what we need is concrete bug reports of specific
instances where the existing WebIDL description of key interfaces is
done in a way that precludes a pure ECMAScript implementation of the
function.
I think the main cases where this is true are interfaces with catchall
getters and setters, or interfaces that are callable (but also have
various methods and properties and are not Functions). I believe most
of these are due to legacy compatibility constraints. Thus, ECMAScript
will need to change to be able to plausibly implement equivalent
interfaces. A change to Web IDL to match current ECMAScript
capabilities would mean it can't actually describe the APIs that exist
in browsers today, and such a description of these APIs would be,
essentially, false. This seems like putting the cart before the horse.
Let me give a concrete example, the HTMLCollection interface from
HTML5: <http://dev.w3.org/html5/spec/Overview.html#htmlcollection-0>.
This interface is defined to have "getter" properties which imply
catchall getters for index and non-index properties. This is
implemented by all existing browsers and is needed for compatibility
with a lot of Web content. It is also required by DOM Level 2 HTML's
ECMAScript bindings: <http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html
>. The fact that ECMAScript 5 can't implement an interface that
behaves like this is an ECMAScript issue, not an HTML issue, in my
opinion, and one that will hopefully be fixed in future editions.
Now, it may be that some non-legacy APIs require special host object
behavior that wouldn't otherwise be implicated by legacy APIs. If
anyone identifies such APIs, then we can look at fixing them.
Regards,
Maciej
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
