W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2011

[Bug 11451] Add a string enum type

From: <bugzilla@jessica.w3.org>
Date: Tue, 20 Dec 2011 23:50:33 +0000
To: public-script-coord@w3.org
Message-Id: <E1Rd9S5-0003hW-RP@jessica.w3.org>

--- Comment #21 from Tab Atkins Jr. <jackalmage@gmail.com> 2011-12-20 23:50:33 UTC ---
(In reply to comment #20)
> I wasn't planning on exposing the enum in any way.  If we make unknown string
> values assigned to attributes be ignored, that can be used to feature detect. 
> Similarly for catching an exception if that's how we make operations handle
> unknown values.
> (In reply to comment #15)
> > Some recent APIs that take dictionaries define the dict as an interface that
> > you can poke at to find support.  It would be nice to have the same with enums.
> Not sure what you mean by defining a dictionary as an interface.  Do you mean
> like `[Callback] interface SomeOptions { ... }`, the style used before
> dictionaries were introduced?

Yes, that's what I'm referring to.

I still think it can be good to expose them somehow, as checking for undefined
on an object somewhere is easier than checking the value after every set, or
catching an exception on every set.

What'll actually happen, if they're not exposed for easy testing, is that
people will just use Modernizr (or some hand-rolled equivalent) to test for the
values they need, store the results in an object, and then use that object for
easy testing.  I don't see a good reason to require this when it can be done
for them.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 20 December 2011 23:50:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC