maplike<> requires spec authors to interact with a real-deal ES Map object (and others), with unfortunate consequences/complexity

[tabatkins]

This is probably deeply related to #254, and may actually end up being a dupe. We'll see.

Currently, the maplike<> declaration talks abstractly about "map entries", defined hand-wavily as a list of key/value pairs. When you actually get down to the ES implementation details, tho, you find that the maplike object contains an internal Map object (a real one, from ES, not a spec abstraction like an Infra map), and the "map entries" are the internal slot of that object, an ES-spec List.

There's no way to put an Infra value into an ES value, tho, which means that if, say, a spec wants to store a list of objects as the "value" in the map, it's a real-deal ES Array object. This, then, means that specs have to be very careful about how they manipulate the object, so they do things correctly and don't accidentally expose implementation details.

Given WebIDL's generally friendly interpenetration with Infra concepts, it feels like maplike<> should be defined in those terms as well, as having its "map entries" just be an Infra map, and the operations defined on that accordingly.

[tabatkins]

(Or maybe I could put another ES-spec List into the List? Dunno, I'm not very up on the abstract ES types. But if that is the case, then this really needs to be laid out clearly in the "Maplike Declarations" section.)

[annevk]

I think this is why maplike<> never really worked and I think I said as much at one point.

[TimothyGu]

Can you be specific about what you want to store? How do you foresee the Infra value getting exposed to JavaScript without any kind of conversion?

[tabatkins]

Upon reflection, I think maplike<> works just fine for what it's intended to do - reflect something that's just like a Map. Maps store arbitrary JS values already, so it's fine to have an intervening "real Map" in there - the values come from the outside world anyway (or are explicitly constructed by the spec to be real JS objects).

I want to be doing something different, and storing a list of values for each key; I don't want the list to be a "real Array", because that's a lot of unnecessary complexity; instead, I want it to be the same as how sequence<> return types are handled, where they can be backed by an Infra list and turn into an Array when they cross the boundary.

It might still be better for maplike<> to be defined in terms of Infra objects, but it's a lesser concern now. I'll go ahead and close this, and re-open it if I have some more particular concern in the future.