1033554 - Can't use unions with dictionaries in WebIDL attributes

Status: RESOLVED INVALID

(Core :: DOM: Device Interfaces, defect)

Description

[:kip (Kearwood Gilbert)]

The CSSOM-View extensions to the Element interface alter the scrollTop and scrollLeft attributes to be union attributes that can contain dictionaries.

When WebIDL.py encounters such an attribute, it throws an exception on line 2818:

raise WebIDLError("An attribute cannot be of a union "
                  "type if one of its member types (or "
                  "one of its member types's member "
                  "types, and so on) is a dictionary "
                  "type", [self.location, f.location])

Please note that Bug 918011 enables support for unions that can contain dictionaries; however, this bug is specifically to enable this for attributes.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The IDL in this spec is not valid IDL, and we don't actually want to implement the behavior it's specifying right now.

In particular:

1)  We don't actually want dictionary return values (not that the spec uses them anyway) except for [Cached] attributes.

2)  When we brought up the idea of attributes with different set and get types (which is what this spec is really doing), we got some pretty strong pushback against it.

Did I completely miss the mailing list discussion that led to the spec looking like it does right now?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note, by the way, that I had a patch to split out the get/set types for attributes.  It's not very hard (though it would need some thinking about IDL syntax.  The real question is whether that's a pattern we actually want in specs.

Comment 3

[Cameron McCormack (:heycam)]

Ignoring dictionaries for a moment, the API design issue already arises as spec authors could write say:

  attribute (Node or double) blah;

and would be free to make blah return a double immediately after a Node is assigned to it, even without new IDL syntax that separates the getter type from the setter type.  I think this is a pattern we shouldn't encourage without good reasons, as it could easily break author expectations that you can immediately get back the same value that you just assigned to the attribute.

Comment 4

[Anne (:annevk)]

Actually, in a theoretical JSIDL we would probably describe a property as

  get ...
  set ...

at which point some overloading on either side seems fairly reasonable. E.g. you could imagine the getter returning SomeClass or null and the setter only accepting SomeClass. Or the getter only returning an Array, and the setter accepting an iterable.

Comment 5

[Cameron McCormack (:heycam)]

Sure, that's what some people have requested in Web IDL, too, but allowing different types in and out is going to break that expectation I mention in comment 3.

Comment 6

[Anne (:annevk)]

Yeah, maybe. On the other hand, setting coerces (e.g. ToString), getting just returns (String), so you already have that.

Comment 7

[Cameron McCormack (:heycam)]

That's a good point.  (Often it will be double-equals equal, though.)