RE: Extended attributes vs. new types

Thanks! I think this does spell out the issue. Now let's turn to shared array buffers and see if I can apply my newfound knowledge.

My main concern is the type explosion issue. It's not the worst thing in the world to add 11 new "MaybeShared" types (9 typed arrays + DataView + ArrayBuffer) and two new typedefs (ArrayBufferView + BufferSource). But it feels pretty silly, and might lead to some repetitive specing and bindings generator code (or some new layer of abstraction to avoid the repetition). And if we end up wanting to capture the by-reference vs. by-copy semantics in the type system, we're in real trouble; now we're up to 44 types and 8 typedefs for the various permutations.

Anne's suggestion ( https://bugzilla.mozilla.org/show_bug.cgi?id=1231687#c18 ) is to couple MaybeShared and by-reference, and use prose for the remaining cases. Maybe that's the way to go. But it sure would be nice if we could just get away with a few extended attributes... which brings us to the last part of the message.

>> I guess the idea would be to make the extended attributes apply to the types instead of the arguments, but how exactly would that help?
>
> At that point, how is that really different from just having a different type?  Unless you can combine the extended attributes, of course.  But if they're mutually exclusive (and [Clamp] and [EnforceRange] are specified as mutually exclusive), there is no real semantic difference between that and a new type...
> 
> There _can_ be the argument that you can apply [Clamp] to a bunch of different types, so you would get a sort of "type explosion" if you created separate types for all of those.  So it might make sense to have [Clamp] that attaches directly to integer types, from that point of view.  That would not have the "have to thread this information through" 
problem I describe above, of course, nor the "hey, we're parametrized over two types, which one should be clamped?" problem.  Nor the "any time we add a new parametrized thing we have to teach it about all these frobs" problem.

One of the big things your message drove home is how extended attributes apply to syntactic productions like dictionary members, attributes, methods, interfaces, etc. and not to types. I guess I knew this intellectually, but my intuition wasn't correctly aligned.

It does seem more intuitive for certain "behaviors", like clamping/range enforcement, and maybe the null-treatment behaviors, to be part of the type. (Corresponding to the current extended attributes [Clamp], [EnforceRange], [TreatNonObjectAsNull], and [TreatNullAs].) In general whenever an extended attribute's processing model shows up entirely inside the ES -> Web IDL type conversion section, often with preludes like  "is being assigned to an attribute... is passed as an operation argument... is being used as a dictionary member...", being part of the type would make more sense.

I think it would be nice to introduce this concept into the spec, and retrofit it onto those extended attributes, but I'm not sure it's worth the trouble for implementers.

It also comes with questions like---should we invent a new concept and syntax, separate from extended attributes? Or should we say that certain extended attributes apply exclusively to types, just like certain of them apply to attributes/interfaces/etc. I guess that latter option would introduce a dependency from the parser to the semantics; to interpret `void f([X] long foo)` you'd be unsure whether [X] is associated with the parameter or the type until you knew if X was one of the type-only extended attributes. (Unless we banned extended attributes on parameters entirely? Are only these type-applicable extended attributes currently used on parameters?)

Thoughts? Mainly on the "is it worth it" question, I suppose.

Received on Thursday, 12 January 2017 19:24:04 UTC