On Sep 24, 2009, at 10:48 AM, Maciej Stachowiak wrote:
On Sep 24, 2009, at 9:47 AM, Brendan Eich wrote:
Probably the best thing to do is to provide detailed technical
review of Web IDL via the W3C process.
Expertise on both sides of the artificial standards body divide may
very well be needed. The rest of this message convinces me it is
needed.
One problem with inviting review via the W3C process is getting
attention and following too many firehose-like mailing lists. es-discuss@mozilla.org
is at most a garden hose, which is an advantage.
Another problem is that not all Ecma TC39 members are W3C members
(their employers are not members, that is).
The converse of all these problems would arise if the spec became an
ECMA spec.
I'm not advocating that, personally -- I'm explicitly encouraging some
kind of collaboration across an artificial divide.
This may be difficult for many reasons, but where the spec ends up is
less important to me (and if you make me choose either-or, I prefer
w3's RF to Ecma's RAND on first principles) than that we have good
collaboration without requiring every TC39 member to join w3c (if
possible).
Do we have to agree on where the spec ends up before collaborating? I
hope not, especially since it seems likely both ES specs and W3C ones
may need to contain sub-specs that hook together, possibly involving
common pieces duplicated among the specs.
Indeed, possibly worse, because ECMA has no formally defined process
for external review of a specification (though ECMA subgroups could
define their own process presumably).
We've had external review of ES5 drafts, and ES4 and ES3.1 materials
before them, for years. This list hears all about the many updates to http://wiki.ecmascript.org/
. We also publish meeting notes freely (we used to publish the formal
minutes but doing so, IIRC, did run afoul of Ecma's rules -- but the
notes are much more complete and useful IMO).
We could recommend avoiding catch-alls as a best practice. However,
many legacy DOM interfaces require catch-all behavior, so it can't
be completely eliminated. If we want to restrict host objects to
what WebIDL allows, but not break the Web, then catch-all getters
and putters have to be among the things it allows.
The problem is containing the old patterns, heading off the temptation
to use them in new APIs.
Beyond this tarpit, we're interested in the best way to linearize
multiply-inherited WebIDL interfaces onto prototype chains, or
whether to use prototype chains at all -- or in the seemingly
unlikely event ES grows first-class method-suite mixins, binding
WebIDL inheritance to those. We would welcome use-cases and
collobaration, at least I would. Who knows what better system might
result?
Yes, linearization of multiply-inherited interfaces (and multiple
interfaces that are present but not inherited) is something that
could use careful review and a better design. When I said "these are
largely Web IDL issues" I mean "not directly issues for the HTML
Working Group". I did not mean to imply that TC 39 shouldn't have
input - it should.
There's probably a better future beyond prototype chains, and I think
the odds of finding that world and colonizing it are greater if we
collaborate somehow. The current situation is making the best of de-
facto standards, rationalizing what's out there.
Possibly TC39 members need to do the main work on mixins, and then
propose something coherent for WebIDL to bind to. But I know of folks
not active in TC39 or not even Ecma mebmers, who are able to
participate in the public HTML5 lists (and of course in whatwg.org),
who do want mixins a la Ruby modules in JS, and their input would help
us make some kind of progress.
But this separation of "producers" and "consumers" is artificial, and
it may miss critical information not expressed in mythical waterfall
requirements docs one might imagine the parties exchange. Systems R&D
benefits from mixing up the experts and opening the silos to cross
disciplines, interest areas, programming audiences, and less
defensible boundaries to-do with standards body politics.
The current division of labor between "core language" (Ecma) and DOM/
WebAPI/WebIDL (W3C) has its advantages, don't get me wrong. But
obviously some things have fallen through the cracks (multiple
globals, split windows, execution rules).
The term I used was "execution model". "scope" is a mis-
transcription.
Are there specific issues other than the concurrency model for
storage APIs?
There are AFAIK interop issues to-do with modal dialogs and events in
major browsers, but I haven't retested lately. Possibly HTML5 has this
all nailed down and browser bug fixes are all that's left to do.
Beyond this, concurrency via workers is great for certain use-cases
but not enough for others.
In TC39 we are talking about formalizing the run-to-completion
execution model of JS, along with asynchronous message passing
concurrency. In particular, we're looking at Promises (precedent from
E) and Futures (differently, in MultiLisp and Alice-ML). At least one
contributor on es-discuss has advocated lower-level components such as
dataflow variables.
It's too early to predict what we'll do but I hear strong consensus in
favor of asynchronous messaging and shared-nothing, with higher-level
abstractions such as Promises favored over lower-level concurrent
programming features such as dataflow variables.
This is for the same reasons given on es-discuss over the last three
years against adding sharp low-level tools such as call/cc, instead
supporting higher-level (very) delimited continuations (Pythonic
generators as in JS1.7).
If ES5 has requirements on this that match ES3, then it has a
requirement that Firefox, Safari and Chrome (and I think Opera?) are
all violating, and likely will continue to violate for the
foreseeable future. That seems like a problem. (Unless we convince
ourselves that the split global object pattern somehow doesn't
actually violate the ECMAScript spec.)
It's a violation, for sure, but no one will be struck down by
lightning. We can live with it a bit longer.
Much of the hoped-for multiple global objects spec that is notoriously
missing from ES1-5 did not appear as an informative document (an Ecma
TR), but it still needs to be done, and it looks like Hixie et al.
have done some of it. A future ES spec would need to say more to work
with the HTML5 spec, and we might want the core language to say a lot
more, not just the minimum necessary to interoperate with the other
spec.
WindowProxy and Window go a step beyond multiple globals, of course,
splitting each global in two (or one proxy and one or more globals
under navigation with cached history).
Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make something up here for ES5.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
