ObservableArray types in namespace

[EdgarChen]

per https://heycam.github.io/webidl/#idl-observable-array,

Observable array types must only be used as the type of regular attributes.

and readonly regular attributes can be a namespace member, so it seems

namespace A {
  readonly attribute ObservableArray<boolean> foo;
};

is allowed.

But in https://heycam.github.io/webidl/#dfn-attribute-getter, we check if the target is interface

2. if target is an interface, and attribute is a regular attribute:
   ....
   4. If attribute’s type is an observable array type, then return esValue’s backing observable array exotic object for attribute.

which makes ObservableArray type in namespace doesn't work.

cc @domenic

[domenic]

This should be disallowed until we have a use case I think. I'm happy to work on a patch tomorrow-ish.

[bathos]

@EdgarChen there's also an assert in the algorithm to get the backing list of a platform object that suggests the intention was to forbid it:

Assert: obj implements an interface with the regular attribute attribute.

(feeling self-conscious realizing this was my fifth comment in a row across different repos following one of yours @domenic - I swear it's just chance, I'm not deliberately looking for em :)

[EdgarChen]

I could provide a PR for this. Thanks!

[tabatkins]

I'm looking into copying some of the spec text for OAs for use in maplike/setlike (to solve #254) and ran into this question - OAs are excluded from a bunch of places that maplike/setlike interfaces are not, and it would be really awkward to add the restriction, but it's really strange to have them be treated differently.

I'm thinking this issue was resolved the wrong way around - it was originally raised just because the OA text was contradictory due to being overly specific in one part, and it got resolved by applying the more-specific condition everywhere. An OA is just... a Proxy object, tho. There's nothing about it that should actually make its use in any of these places problematic.

Would y'all mind if I PR'd to reverse this and do it the other way around instead, allowing OAs in all the places any other interface object is allowed?

[domenic]

I think it'd be best to stay conservative, even if it makes things less consistent... if you want to make things more consistent by disallowing maplikes/setlikes on namespaces though, that seems reasonable?

[tabatkins]

If it actually cost impl effort I can potentially agree, but I don't see how that's the case. (The restriction doesn't cost impl effort either, except in their internal binding generator that parses IDL, but it costs spec effort to remember these odd inconsistencies, and results in oddly-designed APIs when someone blindly designs around the restriction rather than revisiting the original question.)

And looking into this more, it actually seems like the OP accidentally discovered a different error actually - the attribute getter algo runs some steps if called specifically on an interface and with a regular attribute, but those steps should apply to namespaces as well, which can also have (readonly) regular attributes. As currently written, it looks like namespace getters would bypass the security check, for example. Fixing that would have resolved the OP's contradiction as well.

Am I reading this wrong?

[domenic]

I feel like we're talking past each other. We're trying to prevent the spread of unusual patterns in the web spec ecosystem, such as a namespace (supposed to be a collection of functions, maybe with static data) with an observable array property. We should not be loosening those restrictions; if anything we should be tightening them.

[tabatkins]

Ah, that's a reasonable restriction, tho not enforced generally (any other interface value is still allowed as the type of a namespace property). I still think that might mean we have a bug in this algo, which I'll raise as a separate issue.

Putting aside the specific question of OAs in namespaces, I was actually brought to this issue by the commit immediately following the one in #1001 - a352edb - which prevents OAs from being nullable or put into another OA. I couldn't find an issue explaining why this change was made, unfortunately. @EdgarChen, do you remember why you addeed this restriction?

[bathos]

prevents OAs from being nullable

A nullable OA meant you’d hit undefined behavior in the the getter/setter steps for OA attributes (which would seemingly need to do something novel with the backing list?). Unless there were motivations besides fixing the bug, I suspect specifying the missing behavior would permit lifting the constraint.

or put into another OA

It seems like there’s a whole lot that prevents OA<OA> from being coherent currently. Instances are 1:1 with platform objects, allegedly created during define the attributes (but see below*). The getter/setter behaviors of the attributes depend on the backing list / “backing observable array exotic object” (@_@) associations and that accessor behavior would seemingly need to become the outer OA’s own behavior for index-key properties.

* Step 8 in define the attributes creates and “installs” the “backing observable array exotic object”. But when this algorithm runs with the OA-typed regular attributes, the target ... is a prototype! Currently, each prototype apparently gets a unique OA and instances get nuthin.