W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Coordination (was: ES6 Modules)

From: Dirk Pranke <dpranke@chromium.org>
Date: Sun, 14 Apr 2013 09:47:52 -0700
Message-ID: <CAEoffTC36HDHmo5XWZZQ-AM3SywykSMQp8OF3i_Vsaf-hX26dg@mail.gmail.com>
To: Kevin Smith <zenparsing@gmail.com>
Cc: Sam Tobin-Hochstadt <samth@ccs.neu.edu>, Brendan Eich <brendan@mozilla.com>, Robin Berjon <robin@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>, es-discuss <es-discuss@mozilla.org>
On Sat, Apr 13, 2013 at 4:52 PM, Kevin Smith <zenparsing@gmail.com> wrote:

>
>> Put concretely: if Futures are provided via libraries, but you can't
>> assume (require) libraries, then you can't design DOM APIs around Futures.
>> Clearly, one way to solve this is put Futures into the language, but
>> another is to solve the extensibility problem so you can start requiring
>> libraries.
>>
>
> I don't understand this.  Surely you wouldn't design a *platform API* to
> be dependent on userland JS libraries.  No?
>
>
I think I've taken us off into the weeds, and I apologize. What I was
trying to say is that library authors have an advantage over platform
authors, in that they can require other libraries.

If the platform itself provides a mechanism for using and acquiring
libraries (modules), then hopefully it'll be easier to move to
better-designed APIs (or even multiple different APIs) without having to go
back to TC39 for everything.

Of course, you will still have the problems of defining core or standard
libraries and ensuring their quality.

-- Dirk
Received on Sunday, 14 April 2013 16:48:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC