Reflected IDL attributes of type FrozenArray<T>? don't create a FrozenArray about html HOT 6 OPEN

I think that's doable though. Web IDL types are already defined to be wrappers around various things, e.g. we let Promise<T> be represented by PromiseCapability records, which is basically a tuple of (actual JS promise object, resolve function, reject function).

In general there's a lot of possible improvements to the way FrozenArray<> is defined in IDL; see e.g. the discussion in whatwg/webidl#810.

from html.

I think you are correct that this is bogus.

from html.

I've put up some improvements in #10221 (also to address some feedback Olli at one point gave).

@mrego and @alice should probably look at the remainder and can maybe help review what I wrote.

from html.

Belatedly looking at this; apologies for the delay.

Thanks for making the edits in #10221. I am particularly a fan of the change to "get the attr-associated elements".

The "cached attr-associated elements object" part is, I guess, necessary, but it seems like it could just as well have been a change to how FrozenArray is specified. At least, the implementation in Blink works like this:

• There is a FrozenArray type in Blink which holds a vector of IDL objects and is associated with a cached JS FrozenArray of the JS objects corresponding to the IDL objects
• Each Element (IDL) object has a map of attribute to FrozenArray for cached attr-associated elements.
• So the getter for each relevant attribute can return an IDL FrozenArray<Element> which the javascript bindings automatically convert to the associated JavaScript FrozenArray object.
• And, the comparison in step 2 is between elements and the FrozenArray more or less directly.

I don't know enough about how FrozenArray is used elsewhere to know whether it would be possible to specify FrozenArray such that its array is an array of the IDL objects, and the process of converting an IDL FrozenArray is where the conversion of each element in array to the corresponding JavaScript object happens, but that's certainly how it works in Blink right now (at least as far as I understand it).

In that case, step 3 of the getter could quite straightforwardly call "create a frozen array", I think.

I guess that would still leave open the question of how to precisely word step 2; it might need to be something like "if elements contains the same sequence of elements as this's cached attr-associated elements"?

from html.

That might be possible with some changes to Web IDL. It's already roughly how you describe it I think. And yeah, ideally we define the equality operation a bit better. Unfortunately we don't have good helpers for that.

from html.

I guess the tricky part is that the "Frozen" part of "FrozenArray" is a JavaScript concept: https://tc39.es/ecma262/multipage/abstract-operations.html#sec-setintegritylevel

So I guess to specify the IDL FrozenArray the way it's implemented in Blink, you'd have to have some kind of notion of the IDL FrozenArray being basically a container for an immutable sequence and a frozen JavaScript object containing the equivalent T values? As opposed to what it is now, which is really just the JavaScript object.

At which point, unless it's useful for something else for FrozenArray to work that way, we may as well stick with what you've written. I think if you squint, the Blink implementation is equivalent :P

from html.