Replace SpeechRecognitionPhraseList with an ObservableArray

[evanbliu]

This PR replaces SpeechRecognitionPhraseList with ObservableArray.

Closes #168

---

Preview | Diff

[domenic]

This is invalid Web IDL; attributes cannot be sequences.

ObservableArray is probably the correct choice here. See https://webidl.spec.whatwg.org/#idl-observable-array

[evanbliu]

Ohh good call, I'll switch this to ObservableArray

[evanbliu]

On second thought, I'm questioning if this is the right thing to do here for the following reasons:

1. The browser won't be modifying the SpeechRecognitionPhrases, so there's no need for websites to observe changes to this collection and using ObservableArray would imply that the browser's speech engine might add or remove the phrases in the list.
2. I didn't find any other examples of APIs with ObservableArrays as attributes. In Chromium, there's only one non-test usage of ObservableArray.
3. There's already a precedent of creating a new interface type with the sole purpose of encapsulating a collection (e.g. SpeechRecognitionPhraseList, TouchList, FileList).

My suggestion is to keep the SpeechRecognitionPhraseList as-is, or alternatively use a FrozenArray it's crucial to avoid adding a new type. @domenic - What are your thoughts on this?

[domenic]

It's indeed crucial to avoid adding new fake arrays to the web platform. That is a strongly deprecated practice.

The question is whether you want this to be mutable, or only settable by the constructor. If it's supposed to be mutable, ObservableArray is the right choice. If it's only settable by the constructor, then adding a constructor option (that would be a sequence<>) and changing the type to readonly FrozenArray<T> makes sense.

Some recent discussion about this in whatwg/webidl#1495 (comment).

[evanbliu]

I see, it sounds like ObservableArray would be the best choice here since it's mutable.

Do you know why there's still only a single usage of the ObservableArray in Chromium despite being introduced 4 years ago?

[domenic]

I think it's a matter of successive filtering. You'd need:

• To produce a new API
• That needs an array-like type
• That fits into cases (2) or (3) of my linked comment, instead of (1) or (4).

I think it's pretty reasonable to expect only one API to meet those filters over the course of 4 years. We don't create that many new APIs, period, as an absolute number.