W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Web IDL maplike: Allow spec prose to specify how key-type should be compared?

From: Mark S. Miller <erights@google.com>
Date: Mon, 9 Mar 2015 12:11:25 -0700
Message-ID: <CABHxS9iB8SqsSwLf+xHoPWEhO1gOyKQhdorfFTw8YVVD8sg4xg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, David Dorwin <ddorwin@google.com>, public-script-coord <public-script-coord@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Mon, Mar 9, 2015 at 12:05 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Mar 9, 2015 at 11:23 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > (This is one more instance of the general problem I've brought up a
> > few times, that Map/Set aren't customizable in any way and it's really
> > an issue.  There should be an internal "SimpleMap" that just exposes
> > the core methods needed, and which can be swapped out by users or
> > specs for another object undetectably, so that Map/Set operate as an
> > interface contract.)
> ES doesn't really have the concept of "interface" which really is what
> we're looking for here. It always ties interface and implementation
> together into specific classes. Classes which always have a
> constructor and which makes sense on their own.
> Another example of when this problem shows up is in the design of the
> Stream class. The two "ends" of a stream should really be two separate
> objects with a specified interface. Those two objects should always
> work in concert to make up the stream object. However JS doesn't allow
> creation of those two objects without requiring that each object also
> can be instantiated and useful on its own.

That's one of things that's so cool about the Promise constructor pattern:

var resolver;
var promise = new Promise(r => resolver = r);

Couldn't this be applies to streams? (I haven't yet followed streams.)

> The closest thing to "interface" that JS has is "duck type".
> / Jonas

Received on Monday, 9 March 2015 19:11:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC