On Sep 24, 2009, at 11:25 AM, Brendan Eich wrote:
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).
Any TC39 members whose employers can't join could perhaps become
Invited Experts to the W3C Web Applications Working Group, if that
facilitates review.
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.
We already have a spec in progress and it already has a home, so
starting the conversation with a suggestion to move the work elsewhere
struck me as odd and potentially disruptive.
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.
That would probably best be done via a recommendation not to use
catchalls in new APIs (in the Web IDL spec perhaps).
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.
Indeed, because the variance in what's out there makes life more
difficult for authors. I expect it's not possible to get rid of
prototypes from ECMAScript DOM bindings given the constraints of Web
compatibility.
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).
I think we are in agreement that collaboration would enable a better
outcome here. All I meant to do is to point out the proper W3C Working
Group for coordination.
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).
Workers are technically a Web Apps WG spec and not part of HTML5
proper any more. They provide an asynchronous messaging shared-nothing
model, while preventing access to most browser-specific APIs in
anything but the main thread. It would be nice to study whether in-
language concurrency features could work together with the Workers
model rather than being completely separate.
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.
Well, it seems bad to me for the spec to state a requirement that
won't be followed.
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.
Specifying more about multiple global objects would be good, but I
think it's not a case where current browser behavior violates the
ECMAScript spec, so it's not really the same issue.
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.
ECMAScript could just allow host embeddings to make the outermost
scope chain entry be something other than the global object. The main
downside is that this is more loose than is needed and could
technically allow crazy unreasonable things. But it may not be
possible to fully specify the behavior at the ECMAScript level, since
it depends on the notion of navigation. There may be a way to provide
a more narrowly tailored hook.
Regards,
Maciej
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
