Use of FrozenArray<>s in dictionaries is unnecessary and bad

[domenic]

Use of FrozenArray<>s in dictionaries is unnecessary and bad

[toji]

This appears to be a simple copy-paste error, where the attributes from the event were brought over to the associated init dictionary too literally. There's no reason I'm aware of why this needs to be a FrozenArray on the dictionary, though as @petervanderbeken points out it can and should continue to be a FrozenArray on the event itself.

[toji]

Put up a pull request to fix this. We can bring it up at the next call, but I think it'll be more of an advisory "Hey, this is a change that's gonna land" rather than something anyone will actually be concerned about.

[Maksims]

Is it frozen to avoid any modifications of it by the application? Which allows implementers to provide the same array and know that it only gets modified by them. Which eliminates a need to return a new array each time, which is beneficial for GC as many of these arrays can be referenced many-many times each frame.

[petervanderbeken]

The attributes can still return a FrozenArray<XRInputSource>.

But the array passed in the dictionary is not frozen. First a sequence<XRInputSource> is created, and then a new array is created from that but is then frozen. Using a sequence<XRInputSource> would work mostly the same. The constructor can then still create a frozen array from that if that's needed.

Note that as currently written the spec doesn't really work, it also still needs to create a frozen array, since the attributes are defined as being a list, which does not magically convert to a FrozenArray<XRInputSource>.

[AdaRoseCannon]

/agenda Bringing it up at the next teleconference call.