webidl icon indicating copy to clipboard operation
webidl copied to clipboard

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

Open rakuco opened this issue 1 year ago • 5 comments

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.

rakuco avatar Apr 26 '24 14:04 rakuco

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.

kenchris avatar Apr 29 '24 14:04 kenchris

[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.

domenic avatar Apr 30 '24 12:04 domenic

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.

foolip avatar Apr 30 '24 12:04 foolip

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.

annevk avatar Apr 30 '24 14:04 annevk

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?

rakuco avatar Apr 30 '24 14:04 rakuco