Should [SameObject] be allowed with FrozenArray<T>?

[rakuco]

What is the issue with the Web IDL Standard?

The spec currently allows [SameObject] to be used with interface types and object. In w3c/compute-pressure#269 we were wondering if the restriction on FrozenArray<T> makes sense or not.

[kenchris]

When we worked on Orientation Sensor, the idea was exactly that we would get the same object for all calls, and I believe we had to move it to use the FrozenArray for that reason.

[domenic]

[SameObject] is just documentation in the current Web IDL spec so it doesn't really matter. You have to make sure you write your getter steps correctly to specify the actual desired behavior.

[foolip]

I think the problem is that FrozenArray isn't an interface and not the same as object, so a Web IDL validator would complain about it.

[annevk]

Right, we need to replace [SameObject]: #212.

I'd also double check you really want FrozenArray. It uses rather dubious ES5 semantics and not as much is frozen as the name might lead you to believe. Generally I'd try to design APIs differently as to not require that.

[rakuco]

I'd also double check you really want FrozenArray. It uses rather dubious ES5 semantics and not as much is frozen as the name might lead you to believe. Generally I'd try to design APIs differently as to not require that.

My uninformed guess is that at least some of the specs use it as a way to make an attribute return some sort of array, as sequence<T> cannot be used as an attribute type. Do you mean reworking APIs so that they don't return make attribute getters return sequences or using a different type to represent the same thing?