And Niko's excellent post on handles is here: http://smallcultfollowing.com/babysteps/blog/2013/10/18/typed-object-handles/ Sorry for not referencing it in my reply!
On Mon, Nov 18, 2013 at 3:36 PM, Niko Matsakis <[email protected]> wrote: > On Sun, Nov 17, 2013 at 10:42:16PM +0100, Dmitry Lomov wrote: > > Typed Objects polyfill lives here: https://github.com/dherman/structs.js > > Dave and I work on it, current status is pretty close to strawman minus > > handles and cursors (which are a bit controversial at this point and as > far > > as I understand are not is Firefox implementation). > > One correction: > > Handles are implemented in the SpiderMonkey implementation and are > being used in the PJS (nee Rivertrail) polyfill: > https://github.com/nikomatsakis/pjs-polyfill > > My point of view on handles: > > Their design is indeed controversial. I summarized the design > tradeoffs in a blog post [1]. After that post, Dmitry, Dave, and I > basically decided to exclude handles from the typed objects spec but > possibly to include them in other specs (such as PJS) that build on > typed objects. > > As I see it, the reasoning for deferring handles is as follows: > > 1. Handles are not as important for performance as initially imagined. > Basically, the original impetus behind handles was to give users an > explicit way to avoid the intermediate objects that are created by > expressions like `array[1].foo[3]`. But, at least in the SM > implementation, these intermediate objects are typically optimized > away once we get into the JIT. Moreover, with an efficient GC, the > cost of such intermediate objects may not be that high. Given > those facts, the complexity of movable and nullable handles doesn't > seem worth it. > > 2. A secondary use case for handles is as a kind of revokable > capability into a buffer, but for this to be of use we must make > sure we get the details correct. For many advanced APIs, it can be > useful to give away a pointer into a (previously unaliased) buffer > and then be able to revoke that pointer, hence ensuring that the > buffer is again unaliased. Use cases like this might justify > movable and nullable handles, even if raw performance does not. > > However, in cases like these, the details are crucial. If we were > to design handles in isolation, rather than in tandem with the > relevant specs, we might wind up with a design that does not > provide adequate guarantees. Also -- there may be other ways to > achieve those same goals, such as something akin to the current > "neutering" of buffers that occurs when a buffer is transferred > between workers. > > > Niko >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
