On 11:59 AM, Mark S. Miller wrote:
Note that I don't see any realistic way to fix problem #3 in the
ES.next language. My point is only that defensive programming is
tricky even after you've gotten all the formal properties you need. As
ES.next introduces various new abstraction mechanisms, whether
classes, enhanced object literals, proxies, modules, or private names,
the design of these can either help or hurt those attempting to write
defensive abstractions. Any class abstraction that is only useful for
making indefensible instances is worse than useless -- it is actively
harmful, both to security and to serious software engineering.
I share your concern about the unintended consequences of new features.
The dangers are very real, and the patterns can be extremely subtle.
But while #3 is not fixable, there are features of ES5 that make it
easier to live with. For example, if you had built makeTable with
var array = Object.create(null),
length = 0;
and adapted the methods accordingly, then in this example, the leakage
could have been avoided without excessive trickiness. I think this level
of practice is teachable.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
