What I meant by "preserve existing behavior" is that *all current code* must retain the footgun. Any chance must only apply to new code that explicitly opts in to it.
On Tue, Nov 27, 2018 at 10:55 AM Ranando King <[email protected]> wrote: > > Not something you'd want to do often... > > Or ever. This is the foot-gun behavior. The same result can be achieved > with a simple factory class. > ```js > class Example { > //Don't use "this". It was flagged to use the updated prototype behavior. > return Object.create(Example.prototype); > } > Example.prototype.sharedObject = { > counter: 0 > }; > const e1 = new Example(); > const e2 = new Example(); > console.log(e2.sharedObject.counter); // 0 > ++e1.sharedObject.counter; > console.log(e2.sharedObject.counter); // 1 > ``` > This is what I meant when I said that the existing behavior isn't lost. > There are still plenty of ways to achieve the foot-gun behavior if that is > what's desired. What this proposal seeks is a means of making the most > common path foot-gun free. > > Besides, a cleaner result can be achieved by using a static property. > ```js > class Example { > } > Example.counter = 0; > > const e1 = new Example(); > const e2 = new Example(); > console.log(e2.constructor.counter); // 0 > ++e1.constructor.counter; > console.log(e2.constructor.counter); // 1 > ``` > > > On Tue, Nov 27, 2018 at 10:30 AM T.J. Crowder < > [email protected]> wrote: > >> On Tue, Nov 27, 2018 at 3:34 PM Ranando King >> <[email protected]> wrote: >> > The fact that the prototype is a 1st class, (usually) mutable >> > object doesn't change the fact that it is a template. >> >> It fundamentally does, calling prototypes templates rather short-changes >> them. Again, they're live objects: >> >> ```js >> class Example { >> } >> const e = new Example(); >> console.log(e.foo); // undefined >> Example.prototype.foo = "bar"; >> console.log(e.foo); // "bar" >> ``` >> >> (http://jsfiddle.net/pot8cdq6/) A *template* wouldn't demonstrate that >> sort of behavior. Perhaps it's just a semantic point, though. >> >> > As for changing `new` in an incompatible way, doesn't represent a >> > significant or incompatible change in the behavior of `new`. >> >> Of course it does. If it didn't, it wouldn't solve the problem you >> describe wanting to solve. Or was there some opt-in (other than the pragma) >> that I missed? The problem you describe is perfectly valid current code: >> >> ```js >> class Example { >> } >> Example.prototype.sharedObject = { >> counter: 0 >> }; >> const e1 = new Example(); >> const e2 = new Example(); >> console.log(e2.sharedObject.counter); // 0 >> ++e1.sharedObject.counter; >> console.log(e2.sharedObject.counter); // 1 >> ``` >> >> (http://jsfiddle.net/m49jsxof/) Not something you'd want to do often, >> but perfectly valid and I expect there are use cases for it, which changing >> it would break. >> >> Re the rest: Yes, it's complicated to solve for nested properties. But >> again, you just repeat the pattern, and/or use a Proxy; you can certainly >> preserve prototypes as needed. The way in which you do so will vary >> dramatically depending on what your use case is and how much you want to >> copy, etc. >> >> I certainly don't see adding new semantics to `new`. I could see a >> library function setting things up for you, but I think the patterns would >> be so project-specific that it's unlikely to go into the standard library. >> >> I'll step back at this point. >> >> Best, >> >> -- T.J. Crowder >> > _______________________________________________ > 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
