Thank you for your reply! I wanna ask you some questions if you don't mind
Which kind of evidences does TC39 commite need? Because if you read all my answers I shared 4 most popular questions about custom implementation of get and set from enSO and above 200K codes which uses lodash implementation of get. Should I provide evidence from other SO communities like ruSO? Should I found more codes on GitHub? Or may be there is a place where I can post a survey for JS dev community?
You said:
I think it may be worth eventually presenting for Stage 1
Shouldn't we start from Stage 0? :) And IMHO I think it is best to publish it like Stage 0 or Stage 1 to bring this to the attention of developers from all over the world. May there are more problems and/or open ended questions than I discovered?
I didn't get the point with strings? We create a huge amount of strings while developing why are paths so hard to optimize? What are they key differences from usual string? Don't get me wrong I'm not insisting that it's necessary to pass a string, I just want to understand the problem itself
An issue with these is that they don't compose with methods. As soon as part of the object is a Map you now need to use .get(key). Optional chaining does not suffer this limitation and composes with other access patterns.
Although it’s not always required, it’s very helpful to show the Committee examples of the problem from real-world codebases, ideally open-source repositories, like:
It also may be helpful to have statistics showing high usage of similar functions, like Underscore/Lodash’s _.get and _.set, using Sourcegraph or GitHub’s code search. NPM download counts of related packages also can be useful.
It’s good to start from Stage 0 and define, explore, and justify a problem space. Indeed, that’s what you’ve been doing a good job of in this thread. The most important part though is defining the problem statement and robustly justifying why it’s important.
Splitting a string every time the function is called is relatively slow.
It would require allocation and deallocation of multiple substrings each time. Object.get(obj, "a.b.c") requires creating three substrings at each evaluation, while Object.get(obj, ["a", "b", "c"]) requires only creating one array at each evaluation (with three string literals requiring no extra allocation).
Plus, Object.get(obj, "a.b.c") would have to perform a search through "a.b.c" for "."s at each evaluation. This might be a bigger problem than the substring allocation/deallocation.
This would not be a big deal if Object.get(obj, "a.b.c") were evaluated only once, but this is a function that is likely to appear in hot paths, e.g., within loops.
It would essentially encourage developers to write poorly performant code by default.
The engines will not want to make special optimizations for Object.get(obj, "a.b.c"). The engines already have a lot of complexity. So the engine implementors want standard functions to be performant by default and to encourage performant code by default.
All of this is just my prediction from my experiences interacting with the engine implementors. I am not an engine implementor and don’t speak for any of them.
During Stage 0, one should focus on only defining and justifying the problem statement and exploring multiple possible solutions. Sorry for bringing up performance prematurely.