[Bug 14878] Rename const to legacyconst

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14878

--- Comment #15 from Aryeh Gregor <ayg@aryeh.name> 2011-11-23 14:28:55 UTC ---
(In reply to comment #11)
> Can you say more? What were people confused about? If it's the botched C
> operator precedence heritage, that's informative -- that poisons the whole
> well.

It's not operator precedence.  It's confusing even when you're just doing if
(foo & bar).  It's the entire concept of bitfields.  As Yehuda says, C
programmers are used to thinking of variables as actually being sequences of
bits.  A string might be a pointer to an array of characters encoded as UTF-8
and terminated by a null byte, and an int might be a 32-bit value in
two's-complement format.

JavaScript programmers who don't have exposure to lower-level languages are
used to thinking of values as higher-level quantities independent of their
format.  They'll think of strings as a sequence of characters, without thinking
about encoding or delimiters or storage method.  They'll think of numbers as
just numbers, not necessarily encoded in any specific format.

Of course this is wrong -- strings are actually binary-safe UCS-2 with kludges
for non-BMP characters, and numbers are IEEE floating-point that occasionally
behave like two's-complement integers.  And JS gurus do understand this, as do
people who know lower-level languages.  But your average casual scripter just
thinks of numbers as numbers.  He probably knows in theory that the number is
stored as binary, but might not be proficient enough in binary to easily
translate 46 to 101110.  So 46 & 32 makes no sense -- it means 32 sometimes, 0
the rest of the time, with no obvious reasoning unless the scripter actually
delves into the nitty-gritty of how the number is internally represented, which
he otherwise has no reason to ever do.  node1.compareDocumentPosition(node2) &
Node.DOCUMENT_POSITION_PRECEDING is going to have to be copy-pasted voodoo
magic to such a person.

A design goal of the web platform should be that scripters should not *have* to
be exposed to things like binary except where strictly necessary.  Yes, it's
obvious to us.  We also know about garbage collection and deadlocks and
context-switching overhead and the proper use of hash tables vs. linked lists
and the performance tradeoffs of busy loops vs. blocking.  But this is the sort
of thing you shouldn't have to think about in high-level languages, because
most people find it hard and confusing.

This is all in addition to the fact that this pattern of using bitfields is a
lot more verbose than string literals or dictionaries, and probably has no
performance benefit in the typical case.  Node.DOCUMENT_POSITION_PRECEDING
involves retrieving an object property already, and it can't be easily
optimized away by the JIT because window.Node is writable.

(In reply to comment #13)
> Boolean properties of an object are ok if you want to pass a bunch of flags and
> you don't care about doing set union, intersection, or difference (at least not
> efficiently for the case I mentioned: dense sets in [0,31]).

For dense sets in [0,31], bitfields are still more verbose and less usable. 
You have

  if (foo & Foo.a & Foo.b & ~Foo.c & Foo.d)
vs.
  if (foo.a && foo.b && !foo.c && foo.d)

Of course the former can in principle be made more efficient, like if you use
that expression many times and cache it as var bar = Foo.a & Foo.b & ~Foo.c &
Foo.d.  But requiring developers to specify array lengths and types in advance
is also more efficient, and we still don't.  For use-cases where efficiency is
critical, we can expose special highly efficient low-level APIs, like Typed
Arrays.  For almost all use-cases, we should expose APIs that are as easy to
use as possible, as long as they're not really egregiously inefficient.

Not to mention, I'm not aware of any cases where we use dense sets in [0,31]. 
JS bitfield APIs I'm aware of typically only have a few flags, of which authors
will be interested in at most one or two per call.

> We're arguing in this bug not about best practices for most APIs, rather about
> expressiveness in WebIDL, a language used for lots of APIs.

That's fair if you can come up with at least one actual example of a WebIDL
interface where named constants are a good idea.  If there are a whole bunch
where it's a bad idea and none where it's a good idea, that suggests it's
better to strongly discourage it.  It's not like renaming const to legacyconst
would bar spec authors from using it in new APIs, it would just send a strong
hint that they should look into why it's called that before they use it.

-- 
Configure bugmail: http://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 Wednesday, 23 November 2011 14:29:07 UTC