W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2014

Re: Weak set usage in streams

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 26 Nov 2014 15:13:10 -0800
Message-ID: <CA+c2ei8nkG-=bnop=MjVf5pSdq34-oc=URbK=19NBSuxR4VrHw@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
I definitely see no problem in creating a pair of objects that are
"friends" and can access each other's internal state.

Using a WeakMap to specify that relationship seems ok, though I don't
think that's how I'd implement for performance reasons. Instead I'd
have the two objects share a closure and then put state that needs to
be accessible to both on that closure.

/ Jonas

On Wed, Nov 26, 2014 at 1:34 PM, Domenic Denicola <d@domenic.me> wrote:
> Hi all,
>
> In streams we're working through a tricky design problem [1] with a few candidate solutions. The core essence of the problem is that we want something like "friend" classes; a bit more concretely, ReadableStreams want to be able to create Readers which have access to one bit of internal state of the creating stream, viz. whether the stream is "locked" or not. We have two possible designs being considered for this.
>
> One approach is basically to use a shared weak set of "locked streams" to coordinate the two classes. A stream and a reader will collaborate on adding/removing the stream to/from the weak set, and the membership test performs the ability for the reader to tell if the stream is locked or not. A draft of this appears at [2] for those interested in digging in further.
>
> Another approach has the stream vend the capability to get and set the internal bit to the reader, and then the reader can use those abilities to coordinate. A prototype of this approach is at [3].
>
> The reason we aren't just handwaving this away by using internal slots is that we want to support custom user-defined streams with the same capabilities, and would prefer that such streams don't need to redefine the whole reader infrastructure as well. For these purposes the first approach is slightly more author-ergonomic, since any object can be put in the weak set; the second approach would require the custom stream implementers to write a few lines of code exposing their implementation of the internal bit (i.e. the getBit/setBit functions that work for their objects).
>
> I am mainly curious to hear from implementers which of these approaches seems more feasible, especially with regard to performance implications. I've heard scary things about how weak map/set membership can affect an object. If we went with the weak set approach, would this be a nightmare to implement? Would it hurt performance of the object in general?
>
> More generally, should spec authors be comfortable reaching for weak maps and sets when specifying things? They seem like very useful tools for cases like this, where you want to interoperate with user-defined objects whose internal slots you do not control.
>
> [1]: https://github.com/whatwg/streams/issues/241
> [2]: https://gist.github.com/domenic/d421643d95cdec9a9b5b#file-readable-stream-locks-2-md
> [3]: https://github.com/whatwg/streams/blob/e3a0f3c3a776973444ac406512afe0aee0141300/reference-implementation/lib/experimental/exclusive-stream-reader.js#L109-L120
>
>
Received on Wednesday, 26 November 2014 23:14:07 UTC

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