Claude Pache wrote:
The more I consider the issue, the more I think that the most elegant
solution is to complete data properties with an additional
"overridable" attribute, whose purpose is to refine the meaning of the
"writable" attribute in the manner sketched below (in opposition of
having an @@unscopables-like hack).
A new attribute, per property, is safer in general (backward
compatibility) than a per-object flag. A per-object list seems an obtuse
way to encode an attribute, and I am quite sure implementations would
prefer an attribute.
At first glance, I expect that the addition of such an attribute
should not trigger much BC issues, but that needs to be examined more
closely.
If it's opt-in, e.g. we define Array.prototype.contains with
[[Overridable]] among its attributes, then at least MooTools works.
What could break? Code that did not expect 'contains' to exist on
Array.prototype, but did expect assigning to someArray.contains would
make a non-enumerable and/or non-own property. That would seem like
nonsense or broken code, but it could exist for some name and prototypal
relation, you're right.
Only way to find out is to implement and test at scale.
It would be good to hear from implementors on the idea of an
[[Overridable]] attribute. SpiderMonkey has something similar but more
restricted (see
http://dxr.mozilla.org/mozilla-central/source/js/src/vm/Shape.h?from=SHADOWABLE&case=true#1013).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
