1

Object constructor function got several methods during the past updates of js like apply, assign, entries, fromEntries, keys, values...

These would be excellent candidates to be included in object prototype.

Object.prototype.values = function(f) {
    return Object.values(this)
}

We could even combine them to implement map or filter:

Object.prototype.map = function(f) {
    return Object.fromEntries(Object.entries(this).map(f))
}

// now we could do...
obj1 = {a:1, b:2}
obj1.values() // [1,2]
obj1.map([a,b] => ['x'+a: b+1]) // {xa:2, xb:3}

This syntax would have been unquestionably superior compared to eg.

Object.fromEntries(Object.entries(obj1).map([a,b] => ['x'+a: b+1])))

But even

obj1.entries()
    .map([a,b]=>['x'+a: b+1])
    .fromEntries()

is much more readable.

Backward compatibility doesn't seem to be a problem, since further objects in the prototype chain would mask the methods (eg. Array.prototype.map would still work properly).

Other route was taken, and there must be a technical reason. I'm pretty much curious what it is.

Are there any examples (possibly in legacy code) where the above approach would fail?

TylerH
  • 20,799
  • 66
  • 75
  • 101
goteguru
  • 443
  • 3
  • 14
  • 1
    Not seeing any question related to debugging code in this post at all. Are you sure you didn't mean to post this on https://softwareengineering.stackexchange.com/? – Tibrogargan Nov 29 '21 at 21:09
  • 3
    @Tibrogargan Not all questions need to be related to debugging code at all. – Unmitigated Nov 29 '21 at 21:10
  • 2
    Funny enough, the upcoming JavaScript spec introduces `Object.hasOwn(obj, key)` as a more useful alternative to `obj.hasOwnProperty(key)`, for reasons explained [here](https://github.com/tc39/proposal-accessible-object-hasownproperty#readme). – GOTO 0 Nov 29 '21 at 21:11
  • 2
    However, they do need to be on-topic, see https://stackoverflow.com/help/on-topic. @Unmitigated – Tibrogargan Nov 29 '21 at 21:11
  • 1
    Did you consider your [obligations before asking](https://meta.stackoverflow.com/questions/261592/how-much-research-effort-is-expected-of-stack-overflow-users/261593#261593)? You have not mentioned TC-39 committee where these things are discussed and decided upon based, as you said "the technical reasons behind...". – Randy Casburn Nov 29 '21 at 21:11
  • 1
    We can't know the definitive answer to why a language feature was included or excluded. It comes down to implementer preference and a host of discussions that may or may not be tracked. – zero298 Nov 29 '21 at 21:12
  • It's your responsibility as a developer to build your own toolset of the basic building blocks the language provides. Everyone wants things a little different. There are countless packages that offer a wide variety of such utility functions, and you're asking this years later after those "new" methods introduces & discussed. Were where you ~7 years ago when discussions where in place? – vsync Nov 29 '21 at 21:13
  • 1
    We can infer that they don't want to add additional methods to the object prototype itself because those can interfere with regular properties on the object or properties on the object can interfere with the prototype methods. For example: `const obj = {values: [1,2,3]}` would hide/override the `.values()` method if it was on the prototype directly. If you want to know the reasoning for sure, you'd have to sift through the appropriate standards development mailing lists where new methods were being discussed and see if this rationale was mentioned. – jfriend00 Nov 29 '21 at 22:09
  • 1
    Not sure why this was closed as opinion-based, when we have a [canonical question](https://stackoverflow.com/questions/9735026/why-were-es5-object-methods-not-added-to-object-prototype) with well-sourced answers on the question – Bergi Nov 30 '21 at 00:40
  • @zero298 It's not just implementer preference, there is a specification. And the discussions *are* publicly tracked. – Bergi Nov 30 '21 at 00:44
  • That's a complete nonsense @RandyCasburn . 99.9% of SO questions/answers is *documented* somewhere. Many of the *most popular* questions are super basic trivia, presented on the very first few pages of any book or doc about the topic. The point of SO is to help us quickly find the missing information or identify the obstacle which hinders progress. – goteguru Nov 30 '21 at 23:32
  • It's pretty much on topic @Tibrogargan . It's about JS prototype chain and possible errors caused by adding method to the root. One possible answer is: "no, there is no problem, it *could* be implemented that way, but other route was chosen". – goteguru Nov 30 '21 at 23:41

2 Answers2

3

Having too many extra properties on all objects is problematic because it would be difficult or confusing to use those names as regular keys on objects.

For instance, values is a valid key name on an object, e.g. {values: [1,2,3]}. In the example in the question, if this property could be modified, then calling .values() on an object would not always work. If this property is non-configurable, then it would be impossible to use values as a regular key name, which is undesirable.

Unmitigated
  • 76,500
  • 11
  • 62
  • 80
  • Please provide references. – Tibrogargan Nov 29 '21 at 21:14
  • 1
    @Tibrogargan OP asked "*Are there any examples where the above approach would fail?*", and this answer provides a clear one. Not sure what kind of reference you would need for that, a screenshot of a `values is not a function` type error? – Bergi Nov 30 '21 at 00:46
  • The OP asked what the technical reasons are. What you have given might be the reasons, but unless you were part of the working group that released the spec, this is just your opinion. There's probably others that are equally valid. Do you have an actual reference? – Tibrogargan Nov 30 '21 at 01:08
  • 1
    @Tibrogargan My answer consists solely of facts, not opinions. – Unmitigated Nov 30 '21 at 02:36
  • There is nothing in your answer that is incorrect, however unless you can point to some references that conclusively show that these may or may not be the reasons the prototype was omitted in the Object spec. The question itself does not belong on this site purely because it's opinion based. Your answer provides a good explanation, but the question it answers doesn't belong here. – Tibrogargan Nov 30 '21 at 02:43
  • The question is literally "What is the technical reasons behind omitting new Object methods from object prototye in javascript?". The OP needs to rephrase to avoid drawing opinion based answers. Yours is a good response to the question that should have been asked, but as it is the question has little value. – Tibrogargan Nov 30 '21 at 03:07
  • @Unmitigated It's reasonable. So the main problem is that, people are often using object as dictionaries and keys would clash with prototype methods. We could still use the "static version" of the constructor, but designers decided to avoid duplicates. Fair enough. – goteguru Dec 01 '21 at 00:04
1

Adding to what Unmititgated already stated, adding these methods to the prototype would make them unavailable on objects created from null, which shouldn't be the case on newly introduced object methods.

Object.prototype.values = function() {
    return Object.values(this)
}

let obj = Object.create(null);
obj.name = "Peter";
obj.age = 34;

console.log(Object.values(obj)); // works

console.log(obj.values()); // error

The proposal for Object.hasOwn explicitly mentions this aspect.

connexo
  • 53,704
  • 14
  • 91
  • 128
  • Your example alone worth to ask the question (despite the usual hate it generated). I've learned something new. – goteguru Dec 01 '21 at 00:05