Re: Why isn't pointer-type an enum?

There was discussion on using booleans is[NameOfInputDevice] on the list,
but that didn't go anywhere.
(...which I think is a terrible idea.)

It's extremely unlikely that it pre-dated the addition of enums in WebIDL,
as that was introduced in 2011/12/21;
[1] the reason why it was left open-ended is for flexibility wrt vendor
extensions and polyfills. (String enums were
mentioned by Olli when this discussion happened.)

Setting that aside, even for standard JS implementations if the strings are
a known set of variants sounds like
a possibility for optimization. Personally, I think the spec should define
well-known possibilities and define it
in a "open-ended string enum" instead of leaving it the way it is.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20219


On Tue, Mar 10, 2015 at 12:47 AM, Rick Byers <rbyers@chromium.org> wrote:

> I forget the discussion that went into changing pointerType from an 'int'
> to a 'DOMString', but I don't think it pre-dated the addition of enumerations
> to WebIDL <http://www.w3.org/TR/WebIDL/#idl-enums>, did it?  Why didn't
> we use an enum?  Document.visibilityState
> <http://www.w3.org/TR/page-visibility/#VisibilityState> is defined to be
> an enum.
>
> I wonder to what extent this matters in practice.  Obviously it's super
> valuable for non-JS bindings, but I'm not sure how important those are in
> practice.  Will JS extensions like asm.js be able to do additional
> optimizations on enums they can't do on bare DOMStrings?
>
> Again, I'm asking because of my InputDevice proposal
> <https://docs.google.com/a/chromium.org/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#>
> .
>
> Rick
>



-- 
Sangwhan Moon [Opera Software ASA]
Software Engineer | Tokyo, Japan