{Map, WeakMap, etc}.prototype.getRef(key)

Yes!! That class should be called List, and it should exist right alongside Map and Set.

What if the syntax was Map.getRef(myMap, key)?

What would be the difference between this List class and a normal array? Presumably, you'd be required to use .at() to index into it, and some other new method to assign items at a particular index (as I'm assuming this won't be an exotic object the same way arrays are). But, would you drop any methods that are currently found on arrays? If so, which?

And, why would anyone choose to create an instance of List over just using a normal array?

I see ideal encapsulation as designing the smallest API that creates the possibility of doing any kind of work.

I think the pattern of a rich, featureful array makes a lot of sense in a language where the programmer knows what environment the code will run in, but javascript library authors don't (which causes problems).

And to be clear I don't think either getRef or emplace is beyond the boundaries of what good encapsulation dictates should belong in Map or a potential List. I took a closer look at the emplace proposal, and while the syntax of it still feels a bit unquantifiably icky to me, I guess I'm OK with it.

Ok, thanks for the input - I was mostly curious about your point-of-view, as I hadn't heard of this kind of thing before :+1:

1 Like