Re: continuing (or not) to mint new integer constants for existing IDL attributes

On Tue, Jul 9, 2013 at 5:31 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> We've previously discussed what to do with IDL attributes whose values are
> numeric constants, where we want to extend the set of things that the
> attribute represents.  I think the first case that came up was in
> Transforms, where we needed to reflect the new transform types that come
> from CSS Transforms into an SVGTransform object.  Since integer constants
> are considered an API anti-pattern these days, we decided to not introduce
> new numeric values for the SVGTransform::type attribute, but to use
> SVG_TRANSFORM_UNKNOWN for those new types.  We did a similar thing recently
> with the new value for SVGMarkerElement::orientType (for
> orient="auto-start-reverse".
>
> I'm having second thoughts on this.  I don't think we're making things worse
> by adding new numeric constants to use for existing IDL attributes.  By not
> introducing new values for the new attribute values, we make it harder for
> the author.

In what way are we possibly making it harder for the author?  They're
*not supposed to* be using those constants, and we are supposed to
make sure that there are sufficient alternatives for whatever the
constants were being used for previously.  Assuming we're doing our
jobs correctly, what we do with the constants should be of no
consequence whatsoever to authors.  So, let's just do the simplest
possible thing and make everything return the one new value.

> (We obviously don't want to introduce new attributes that take numeric
> constants; we should be using IDL enums -- string values -- instead.)
>
> I'd like to hear people's opinions on this.  As a single data point, I
> notice new CSS at-rules get new numeric constants for CSSRule::type.

This is due to inertia, not intention.  We haven't gone to the effort
to spec out a CSSRule::ruleName attribute or whatever.

~TJ

Received on Wednesday, 10 July 2013 02:32:37 UTC