- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 19 Oct 2011 22:26:37 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-script-coord@w3.org
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