https://www.npmjs.com/package/decorator-memoize https://www.npmjs.com/package/memoized-decorator https://www.npmjs.com/package/memoize-decorator
Relevant? On Tue, 12 Sep 2017 at 03:18 Andrea Giammarchi <[email protected]> wrote: > Steve it's not solved in any other way. Even if you use a WeakMap with an > object, you gonna lazy attach properties to that object. > > I honestly would like to see alternatives, if any, 'cause so far there is > a benchmark and it proves already lazy property assignment is around 4x > faster. > > So, it's easy to say "it's not the best approach" but apparently hard to > prove that's the case? > > Looking forward to see better alternatives. > > > On Mon, Sep 11, 2017 at 8:15 PM, Steve Fink <[email protected]> wrote: > >> On 9/11/17 5:36 AM, Matthew Robb wrote: >> >> > I think it's irrelevant if internally VMs are not too happy. VMs are >> there to solve our problems, not vice-versa ;-) >> >> This ^ is very important for everyone to get on board with. Regardless >> the cost should be negligible as the shape is only changing at the point of >> delayed init. This will cause, for example V8, to deop the object and have >> to build a new hidden class but only the one time. I guess it would >> potentially be interesting to support an own property that when undefined >> would delegate up the proto chain. >> >> >> (I don't know, but) I would expect it to be worse than this. The shape is >> changing at the point of delayed init, which means that if an engine is >> associating the possible set of shapes with the constructor (or some other >> form of allocation site + mandatory initialization), then that site will >> produce multiple shapes. All code using such objects, if they ever see both >> shapes, will have to handle them both. Even worse, if you have several of >> these delayed init properties and you end up lazily initializing them in >> different orders (which seems relatively easy to do), then the internal >> slot offsets will vary. >> >> You don't need to bend over backwards to make things easy for the VMs, >> but you don't want to be mean to them either. :-) >> >> Not to mention that the observable property iteration order will vary. >> >> On Mon, Sep 11, 2017 at 7:09 AM, Andrea Giammarchi < >> [email protected]> wrote: >> >> Hi Peter. >>> >>> Unless you have a faster way to do lazy property assignment, I think >>> it's irrelevant if internally VMs are not too happy. VMs are there to solve >>> our problems, not vice-versa ;-) >>> >>> Regards >>> >>> >>> >>> On Mon, Sep 11, 2017 at 11:54 AM, peter miller <[email protected] >>> > wrote: >>> >>>> Hi Andrea, >>>> >>>> ``` >>>>> class CaseLazy { >>>>> get bar() { >>>>> var value = Math.random(); >>>>> Object.defineProperty(this, 'bar', {value}); >>>>> return value; >>>>> } >>>>> } >>>>> ``` >>>>> >>>> >>>> Doesn't this count as redefining the shape of the object? Or are the >>>> compilers fine with it? >>>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
