I'm working on a JavaScript project, and was just wondering why an object instance doesn't inherit the defineProperty()
and other methods, rather than having to call the superclass (superobject?) Object
method.
I've looked at the MDN docs, and there are in fact "non-standard" property methods.
But those are deprecated. Why would the move be to the Object
methods?
It seems to me that something like instance.defineProperty(...)
is better than Object.defineProperty(instance, ...)
. I would say the same about some of the other Object methods as well.
Object. defineProperty allows you to set whether or not the property is enumerable, writable, and configurable as well as a value or a get/set (getter/setter) pair (see MDN Object. defineProperty).
Syntax: Object. defineProperty(obj, prop, descriptor)
Parameters. The object on which to define the property. The name or Symbol of the property to be defined or modified. The descriptor for the property being defined or modified.
Object properties are defined as a simple association between name and value. All properties have a name and value is one of the attributes linked with the property, which defines the access granted to the property. Properties refer to the collection of values which are associated with the JavaScript object.
It's to avoid collisions - in general, issues with objects that do not have the property with the value that you expect.
Objects in JS are often used as key-value-maps, and the keys can be arbitrary strings - for example __defineGetter__
, hasOwnProperty
or something less special. Now when you want to invoke such a function on an unknown object - like hasOwnProperty
is often used in generic enumeration functions, where any JSON might be passed in - you can never be sure whether you got a overwritten property (that might not even be a function) or the original which you want, or whether the object inherits the property at all. To avoid this issue (or also this IE bug), you'd have to use Object.prototype.hasOwnProperty.call
- that is ugly.
So, namespacing all those functions on Object
is only useful, it's a cleaner API that separates the reflection methods from the object's application interface. This also helps optimisation (simplifying static analysis) and makes it easier to restrict access to the reflection API in sandboxes - at least that was the design idea.
You might be happy to have a defineProperty
around in the prototype, but you can only use it safely when working with known objects. If you still want it (as you know when to use and when not), you could use
Object.defineProperty(Object.prototype, "defineProperty", {
writable: true,
enumberable: false,
value: function(prop, descr) {
return Object.defineProperty(this, prop, descr);
}
});
It's done like that to avoid collisions - remember, every method on Object.prototype
is a method in every single user-defined object, too.
Imagine an object where you'd want a custom method defineProperty
- that would completely break things when Object.defineProperty
was on its prototype instead.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With