Consider dictionaries and sequences instead of non-constructible interfaces and frozen arrays

[domenic]

Since they are only used in a return value, using mutable data structures would be more developer friendly.

[beverloo]

It didn't feel very common for APIs to return (sequences of) dictionaries, but I agree that there's little value in having interfaces. Does https://github.com/beverloo/contact-api/compare/dictionaries make sense to you?

The one argument against this is that it makes feature detection of particular properties harder. Does Browser A support telephone numbers? That's worth considering since it's a non-goal to expose all information stored in a contact.

[domenic]

Looks pretty good. Note however that you no longer need nullability; dictionary entries are optional by default. And it's more idiomatic to leave those properties un-set than it is to create the properties but set their values to null.

As for feature detection, I guess I don't quite understand. Even in the interface version, having the IDL attribute implemented doesn't necessarily mean the browser is going to expose that information.

[beverloo]

That's much nicer indeed - thanks!

Regarding feature detection, a developer would be able to know whether telephone numbers are supported by checking whether ContactInfo.prototype.tel exists. That's something we lose with a dictionary, but that may be OK as select() will throw a TypeError for invalid values of the ContactProperty enum.