for (key in obj) // do
obj = Object.create(null)
obj = {}
Object.keys(obj).forEach(k
obj = Object.create(null)
obj = {}
obj = {}
If it wasn’t clear, i was mentioning 2 ways of initializing, not that you should reassign immediately.
Naming is a difficult but critical aspect of conceptualizing a solution [1]. Programming, even when ad-hoc, relies on an internal conceptual model to guide the programmer. It pays to be pedantic with language.
A "prototype" per common understanding and dictionary definition strongly implies the act of "copying". Per that sense, the "prototype" of an Object is distinct object with its own distinct life-cycle and state space trajectory.
So it should be clarified here that the OP exploit is not an inherent weakness of prototype based OO approach, in principle. The Javascript "prototype" is really a "parent delegate". It is a Delegated-Parent Inheritance language, and the OP exploit is a feature/bug of delegate based composition approaches, by definition.
This inability by otherwise (obviously) intelligent people in naming things is an unfortunate pattern in computer science and software development. A historic favorite is "dynamic programming".
({}).delegate === ({}).constructor.withDelegate
({}).parent === ({}).creation.withParent
constructor sum(a, b) { return a + b } Object.define_method('env') { { RUBYOPT: "-e puts 123" } }
$ RUBYOPT="-e 'puts 123'" env ruby
Traceback (most recent call last):
ruby: invalid switch in RUBYOPT: -e (RuntimeError)
And to use -r file needs to be .rb
delete Object.prototype.__proto__;
delete Object.prototype.__proto__;
a = {};
a.constructor.prototype.x = 1;
a.x == 1