> Not in a prototypical language. Again, prototypes are living objects
(even though lots of code doesn't make use of that fact).
The fact that the prototype is a 1st class, (usually) mutable object
doesn't change the fact that it is a template. Templates come in many
forms, not all of which are of the "rubber stamp" variety. The design of ES
is such that for any given object, all properties of its prototype behave
as though they are own properties (`var a = {__proto__: {b: 42}};` -> `a.b
=== 42;), even though they're not (`Object.keys(a).length === 0`). Further,
any attempt to change the top level value of any prototype property through
the object causes an own property to be created on the object instead of
modifying the prototype. It is this behavior that I'm referencing when I
say that a prototype serves the role of a template for classes in a
prototype-oriented language. When you want a property to exist in every
instance of the class, you can either manually create the property in the
constructor, or you can put it on the prototype and rest assured that every
new instance will behave as though it has its own copy (unless the value is
an object).
As for changing `new` in an incompatible way, doesn't represent a
significant or incompatible change in the behavior of `new`. The only thing
different `new` will do is mark an internal slot on the newly created
object, flagging it to use the new behavior when accessing `__proto__`.
There is no other behavioral change for `new`. The real behavior of this
proposal happens when accessing an object data property from the flagged
object's prototype.
> Depending on the use case, you just repeat the pattern, or use a Proxy,
or...
Let's say you've got some heavily nested structure on a prototype property.
Repeating this process for every nested object in the structure could be
excessively time consuming and certainly an exercise in tedium to write.
What if the language did it for you?
* On one extreme, you get the public-fields proposal. That just introduces
new foot guns for very little gain.
* In the middle, you've got values applied to the prototype, and then
applied again to the instance in the constructor. That blows the point of
having mutable prototypes.
* On the other extreme, you put properties on the prototype only. Then have
the language treat changes to the object property's structure or data as a
cue to copy.
This proposal is essentially what you're describing, except carried out by
language itself using data and structure mutations as the trigger. In all
honesty, I would really like to use your `Object.create` approach instead
of `Object.assign`, but since the object property may have a structure
including needed prototypes, and the original cannot be modified, that idea
won't work. The problem with your approach is that it doesn't account for
cases where the sub-property is on a prototype of a sub-object.
On Tue, Nov 27, 2018 at 1:32 AM T.J. Crowder <
[email protected]> wrote:
> On Tue, Nov 27, 2018 at 3:24 AM Ranando King
> <[email protected]> wrote:
> > ...and from a class POV, the prototype serves the role of the
> > class template...
>
> Not in a prototypical language. Again, prototypes are living objects
> (even though lots of code doesn't make use of that fact). Code that
> *does* isn't uncommon, and can't just suddenly work differently.
>
> As Jordan said, `new` can't be changed in an incompatible way.
>
> > As for your suggestion, that doesn't work when the element being
> > changed is on a sub-property of the object.
>
> Depending on the use case, you just repeat the pattern, or use a Proxy,
> or...
>
> -- T.J. Crowder
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
