<div dir="ltr">> <span style="font-size:12.8px">please use normal method-calls instead, which are more maintainable</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">no, thanks.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">WeakMap's implicit-garbage-collecting feature is error-prone, hard to validate with tests, and generally becomes unmaintainable over time.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">no, thanks.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">We were discussing patterns here, nothing to "please don't" and IMO, d</span><span style="font-size:12.8px">ogma oriented rules are over-engineered anti-pattern too.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Let's not make this ML an awkward place for who wants to just learn or explore JS language features, thanks.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 14, 2017 at 9:55 AM, kai zhu <span dir="ltr"><<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>inline</div><span class=""><div><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>```js<br>class A {<br>  #random;<br>  get random() {<br>    return this.#random ||<br>          (this.#random = Math.random());<br>  }<br>}<br><br><br>// transpiled<br>var A = function (wm) {<br>  function A() {<br>    wm.set(this, {random: void 0});<br>  }<br>  Object.defineProperties(<br>    A.prototype,<br>    {<br>      random: {<br>        configurable: true,<br>        get: function () {<br>          return wm.get(this).random ||<br>                (wm.get(this).random = Math.random());<br>        }<br>      }<br>    }<br>  );<br>  return A;<br>}(new WeakMap);<br>```</span></blockquote></div></div></blockquote></div><div><br></div></span><div>- overloaded getters/setters and Object.defineProperties are generally <i>over-engineered </i>anti-patterns in javascript-programming</div><div><span class="m_773777313504756965Apple-tab-span" style="white-space:pre-wrap">    </span>* please use normal method-calls instead, which are more maintainable</div><div><br><div>- WeakMap is an <i>over-engineered </i>anti-pattern in javascript-programming</div><div><span class="m_773777313504756965Apple-tab-span" style="white-space:pre-wrap"> </span>* they are inferior to using a plain-object cache-dictionary in pretty much every use-case.</div></div><div><span class="m_773777313504756965Apple-tab-span" style="white-space:pre-wrap">    </span>* WeakMap's implicit-garbage-collecting feature is error-prone, hard to validate with tests, and generally becomes unmaintainable over time.</div><div><br></div><div>```javascript</div><div><div>/*jslint node: true */</div><div>'use strict';</div><div><br></div><div>function LazyClass() {</div><div>    this.cacheDict = {};</div><div>}</div><div>LazyClass.prototype.<wbr>getRandomCached = function () {</div><div>    this.cacheDict.random = this.cacheDict.random || Math.random();</div><div>    return this.cacheDict.random;</div><div>};</div><div>LazyClass.prototype.clearCache = function () {</div><div>    this.cacheDict = {};</div><div>};</div><div><br></div><div>var lazyObject = new LazyClass();</div><div>console.log(lazyObject.<wbr>getRandomCached());</div><div>console.log(lazyObject.<wbr>getRandomCached());</div><div>lazyObject.clearCache();</div><div>console.log(lazyObject.<wbr>getRandomCached());</div></div><div>```</div><div><br></div><div><img id="m_773777313504756965B5B994F3-6A10-49F5-B19E-F2500CD2B7FE" src="cid:742B723E-3C8D-4776-AB5D-93932D1733A7"></div><div><br></div><div><br></div><br><div><blockquote type="cite"><div><div class="h5"><div>On Sep 13, 2017, at 9:32 PM, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:</div><br class="m_773777313504756965Apple-interchange-newline"></div></div><div><div><div class="h5"><div dir="ltr">> <span style="font-size:12.8px">Maybe you mean "will behave more or less as if (except more efficiently)"?</span><br style="font-size:12.8px"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">no, I meant: it will transpiled into something using private WeakMaps.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I don't have any interest in talk nanoseconds for something unrelated to the topic though.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Best Regards</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 13, 2017 at 1:54 PM, Alex Kodat <span dir="ltr"><<a href="mailto:alexkodat@gmail.com" target="_blank">alexkodat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What do you mean by “will be transpiled through”? My understanding of the private property proposal is that private properties will be in fixed slots (inaccessible outside the class) in the object so there would be no WeakMap. Maybe you mean "will behave more or less as if (except more efficiently)"?<br>
<br>
----<br>
Alex Kodat<br>
<br>
From: es-discuss [mailto:<a href="mailto:es-discuss-bounces@mozilla.org" target="_blank">es-discuss-bounces@moz<wbr>illa.org</a>] On Behalf Of Andrea Giammarchi<br>
Sent: Wednesday, September 13, 2017 2:31 AM<br>
<span>To: Steve Fink <<a href="mailto:sphink@gmail.com" target="_blank">sphink@gmail.com</a>><br>
Cc: <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
</span>Subject: Re: Lazy evaluation<br>
<span><br>
> The properties already existed, so defineProperty shouldn't modify the order IIUC<br>
<br>
well, nope. the property existed in the prototype, not in the object.<br>
<br>
anyway, I guess private properties, that are a possible solution, will be transpiled through a WeakMap so that most likely anything discussed in here won't make sense and the future code would look like the following<br>
<br>
```js<br>
class A {<br>
  #random;<br>
  get random() {<br>
    return this.#random ||<br>
          (this.#random = Math.random());<br>
  }<br>
}<br>
<br>
<br>
// transpiled<br>
var A = function (wm) {<br>
  function A() {<br>
    wm.set(this, {random: void 0});<br>
  }<br>
  Object.defineProperties(<br>
    A.prototype,<br>
    {<br>
      random: {<br>
        configurable: true,<br>
        get: function () {<br>
          return wm.get(this).random ||<br>
                (wm.get(this).random = Math.random());<br>
        }<br>
      }<br>
    }<br>
  );<br>
  return A;<br>
}(new WeakMap);<br>
```<br>
<br>
<br>
<br>
<br>
<br>
<br>
</span><span>On Tue, Sep 12, 2017 at 10:39 PM, Steve Fink <mailto:<a href="mailto:sphink@gmail.com" target="_blank">sphink@gmail.com</a>> wrote:<br>
My intent was only to respond to the performance analysis, specifically the implication that the only performance cost is in building the new hidden class. That is not the case; everything that touches those objects is affected as well.<br>
<br>
Whether or not it's still the right way to accomplish what you're after, I wasn't venturing an opinion. I could probably come up with a benchmark showing that your WeakMap approach can be faster -- eg by only accessing the property once, but feeding the old and new versions of the object into code that executes many many many times (doing something that never looks at that property, but is now slightly slower because it isn't monomorphic). But I suspect that for practical usage, redefining the property *is* faster than a WeakMap.<br>
<br>
If I were to look beyond for other solutions for your problem, then I'm just speculating. Can decorators populate multiple properties once the expensive work is done?<br>
<br>
I really want to tell the VM what's going on. I guess if it knew that accessing a getter property would convert it into a value property, and that it was doing something that would access the getter, then it could know to use the outgoing shape instead of the incoming shape. If only it knew that the getter was pure... but that way lies madness.<br>
<br>
Given that most code that would slow down would also trigger the lazy defineProperty(), it's really not going to be that much of an issue. Any access after the first will see a single shape.<br>
<br>
meh. Just take the perf hit, with awareness that you may be triggering slight slowdowns in all users of that object. Or you might not. I doubt it'll be that big, since you'll probably just end up with an inline cache for both shapes and there won't be all that much to optimize based on knowing a single shape.<br>
<br>
Oh, and I think I was wrong about property enumeration order. The properties already existed, so defineProperty shouldn't modify the order IIUC. (I am awful with language semantics.)<br>
<br>
On 9/11/17 2:48 PM, Andrea Giammarchi wrote:<br>
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.<br>
<br>
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.<br>
<br>
So, it's easy to say "it's not the best approach" but apparently hard to prove that's the case?<br>
<br>
Looking forward to see better alternatives.<br>
<br>
<br>
</span><span>On Mon, Sep 11, 2017 at 8:15 PM, Steve Fink <mailto:<a href="mailto:sphink@gmail.com" target="_blank">sphink@gmail.com</a>> wrote:<br>
On 9/11/17 5:36 AM, Matthew Robb wrote:<br>
> I think it's irrelevant if internally VMs are not too happy. VMs are there to solve our problems, not vice-versa ;-)<br>
​<br>
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.<br>
<br>
(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.<br>
<br>
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. :-)<br>
<br>
Not to mention that the observable property iteration order will vary.<br>
<br>
</span><span>On Mon, Sep 11, 2017 at 7:09 AM, Andrea Giammarchi <mailto:<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmai<wbr>l.com</a>> wrote:<br>
<br>
Hi Peter.<br>
<br>
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 ;-)<br>
<br>
Regards<br>
<br>
<br>
<br>
</span><span>On Mon, Sep 11, 2017 at 11:54 AM, peter miller <mailto:<a href="mailto:fuchsia.groan@virgin.net" target="_blank">fuchsia.groan@virgin.n<wbr>et</a>> wrote:<br>
Hi Andrea,<br>
```<br>
class CaseLazy {<br>
  get bar() {<br>
    var value = Math.random();<br>
    Object.defineProperty(this, 'bar', {value});<br>
    return value;<br>
  }<br>
}<br>
```<br>
<br>
Doesn't this count as redefining the shape of the object? Or are the compilers fine with it?<br>
<br>
<br>
______________________________<wbr>_________________<br>
es-discuss mailing list<br>
</span>mailto:<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div></div><span class="">
______________________________<wbr>_________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br></span></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>