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
