What Tab said. The use of numeric constants is the sort of C++-ism that
spec authors should actively be discouraged from. If XHR is to be cited,
let it be as cautionary tale.
On Feb 15, 2012 7:52 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> On Wed, Feb 15, 2012 at 9:16 AM, Dominique Hazael-Massieux <dom@w3.org>
> wrote:
> > (trimming cc as originally requested)
> >
> > Le mercredi 15 février 2012 à 17:05 +0000, Marcos Caceres a écrit :
> >> > There are strong ties, in the sense that the said API would be
> exposing
> >> > a readyState property (similar to XMLHttpRequest, HTMLMedia, etc).
> >>
> >> I'm not sure there is any relationship to the internal state of an
> >> object and using object.SOME_HARD_TO_REMEMBER_AND_TYPE_THING…
> >> specially when you can just type "thing".
> >
> > That's not the point; the point is that if we use strings for a
> > readyState property in one API, and numeric values in many others, we
> > would have scripts that have code that looks like:
> >
> > if (XHR.readyState == 4) {
> >
> > }
> > if (P2P.readyState == "done") {
> >
> > }
> >
> > That seems utterly confusing, hard to remember, hard to teach, etc.
>
> The old way is *so bad* that breaking with legacy practices is
> justified. I'm in favor of this as a general rule for all new APIs.
>
> ~TJ
>
>