[Bug 14878] Rename const to legacyconst

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

--- Comment #14 from Yehuda Katz <wycats@gmail.com> 2011-11-22 06:45:14 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > Why are bitmasks superior to boolean properties?
> 
> I'm not sure where that q came from. I'll give an a if you answer my q below
> :-|.
> 
> 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]).
> 
> 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.
> 
> /be
> 
> > (In reply to comment #11)
> > > (In reply to comment #10)
> > > > Bitmasks are not a good user-facing API for JavaScript. Anecdotally, SproutCore
> > > > 1.x used bitmasks for some state management code in our data store API, and it
> > > > was one of the most confusing (and "weird") parts of that API.
> > > 
> > > Can you say more? What were people confused about?

People were confused primarily because the bitmask API operates at a level of
abstraction that is markedly different from the rest of the abstraction. Here
is an example of the API in action:

    if (record.get(‘status’) & SC.Record.READY) { ... }

In most cases, this API would look more like:

    if (record.isReady) { ... }

which is both shorter and more obvious for people not familiar with bitmasks in
general. When I used the term "cargo-culting", what I meant was that an API
totally appropriate for the kinds of low-level abstractions common in C
(involving inspection of bits in a numeric type) feel out of place in a higher
level language like JavaScript, where numbers are almost always just numbers.

-- 
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 Tuesday, 22 November 2011 06:45:22 UTC