Re: [heycam/webidl] Disambiguate / explain maplike vs record (#303)

You don't have to service my context, but I'm coming to the spec as essentially reference to explain what I'm trying to read in existing IDL. In an draft I saw a return value of e.g. maplike<unsigned short, DataView> and someone requested it be changed to record instead. Ok, but why? What are these? Off to the webidl spec to try to understand.

Only, no. I try to read maplike and I see

- can be applied to interfaces. (not meaningful to me yet in this context)
- is an ordered list of key values
- these are 'map entries'
- keys are unique
- map entries are empty by default.. 
- some api notes about methods similar to ECMAScript Map
- can't have certain names
- rest of description doesn't seem key to comparing to record

Ok, off to record
- is ordered arrays of key to values
- these are 'mappings'
- can't represent a constant record
- key types are limited to string,string,string
- passed by value
- oh, can't be used as an attribute (I only caught this when trying to write this response here)
- typename is based on a rule...

After reading those two, I see lots of spec text, it's trying to say something, but I have little to no understanding of what the difference is. Both are mapping K->V. Preparing this response I guess I see that record can have duplicate keys. I'm still missing the succinct high level point that makes them different. I really have no idea how to interact with a record, how are contents of the ordered associative arrays mapping instances referred to?

- How would code hold one or the other differently?
- Why should an API return a record and not a mapping?
- I hear record is new, what's the web been doing in all its previous years? Does record represent old concepts not describable by IDL?

I think I more understand maplike, and really don't understand what record is.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/303#issuecomment-278217809