- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Tue, 10 Mar 2015 14:36:54 -0700
- To: Brendan Eich <brendan@secure.meer.net>
- Cc: Jason Orendorff <jason.orendorff@gmail.com>, Jonas Sicking <jonas@sicking.cc>, "Mark S. Miller" <erights@google.com>, "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 Mar 10, 2015, at 2:18 PM, Brendan Eich wrote: > Jason Orendorff wrote: >> So the spec has a way to say "ok, create a bunch of objects and hook >> 'em up like so", but scripts don't. A bit of "putting magic into the >> API" seems unavoidable to me, as this is exactly the property you're >> after, right? > > And as Mark showed, with ES6 the magic can be self-hosted -- but specs should not over-specify like that, at least not without a lot of care to avoid observables we don't want to specify (now or in future; as Tab reminds everyone, future JS standards own some map and set primitives to workalikes and extensions). Right, if you want the entanglement to be tamper proof you need some sort of tamper proof private state. Mark accomplished this via weak maps but in the future other mechanism could be used. Also, there are various schemes that might be used to ensure that a constructor can only only [[Construct]] invoked by an authorized caller. Modules help with this. I could give examples. What I think might be the biggest issues about such entangled objects is that it significantly complicates how you might have to go about subclassing an abstraction that creates them. For example, assume that instantiating an instance of a Stream class gives you access to two entangled end points. Do you want a subclass of Stream to be able to individually over-ride the class of each end point. If so you need to come up with a protocol for providing the end point subclasses and also protocol that allows new subclass instances to get entangled. Allen
Received on Tuesday, 10 March 2015 21:37:25 UTC