Is this to say that no new feature is allowed to introduce breaking changes in existing code?
On Tue, Nov 27, 2018 at 1:00 PM Jordan Harband <[email protected]> wrote: > 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
