Re: [WebIDL] Remove string constants

On Wed, Oct 19, 2011 at 7:25 PM, Anne van Kesteren <annevk@opera.com> wrote:
> Strings are intrinsically meaningful and therefore have no need for
> constants in APIs for the platform. See XMLHttpRequest.responseType and the
> <canvas> 2D API for examples. We should remove string constants so people
> (e.g. public-web-perf) will not use them and introduce inconsistent APIs.
>
> We should probably also strongly deprecate numerical constants, maybe even
> go as far as naming them "legacyconstant", since they are generally
> considered a poor API too and where it makes sense we have moved away from
> them (e.g. with exceptions).

I'm somewhat split on this issue.

>From one point of view I completely agree. Functions that take string
arguments as enums, should use clear enough string values that there
should be no need to use Foo.BAR syntax.

Further, having string constants is likely to cause people to feel the
need to pass Foo.BAR rather than "bar" as argument in thinking that
it's more correct or otherwise better. Cargo cult copying is likely to
significantly add to this problem too.

However, there still is an argument for the constant, which is that it
enables feature detection. With for example
XMLHttpRequest.responseType, there is no good way to check what types
a browser supports. This isn't a big deal right now since all browsers
which support .responseType at all, support the full set of values.
However as we add more values that will no longer be the case (we
already have 3 additional values that we support in Gecko).

So if we can find another solution for this problem, then I'm fine
with dropping support for string constants.

/ Jonas

Received on Thursday, 20 October 2011 05:27:42 UTC