[Bug 12248] Make objects first-class API citizens

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

--- Comment #17 from Brendan Eich <brendan@mozilla.org> 2011-03-08 04:01:21 UTC ---
(In reply to comment #15)
> > No spec is complete.
> 
> Yes, but that may not be a good thing, given past web experience.

My point about economics still applying stands. We don't have infinite funds to
try to specify everything, and at formal but quite real level, we have Goedel's
Incompleteness Theorem to contend with.

All specs are incomplete. Choosing one's spec-battles is important, and basing
the choice on real-world pain points instead of only-in-spec-writers'-minds
ratholes is crucial.

> Some of the people in this discussion have as a high priority preserving JS
> semantics in all cases, so they think losing non-data properties on objects
> passed as a way of grouping some data is a worse deal than the possibility of
> underspecified behavior due to weird getters.  I'm not entirely sure I agree
> myself; I see the use of getters here as a definite edge case, and at that
> point the question becomes how much that edge case is worth catering to.  Is it
> worth the fact that behavior will have to be explicitly undefined in some cases
> (and that this set of cases may not even be describably adequately)? 
> 
> Maybe it is.  Maybe it's not.

This is the wrong debate to have.

First, because we can't guess at good future uses of accessors, but they are
part of JS, and developers are using them and will use them more in the future.

Second, because self-hosting, a native vs. JS implementation substitution
principle, wants DOM methods to process their parameters as if they were
written in JS [*], as much as possible. Every time we make some ad-hoc (or
even, eventually, systematic) crippling of JS semantics, we make the DOM that
much less self-hostable or virtualizable in JS.

If you don't care about these, then we can revert the recent WebIDL changes to
make JS the primary binding language and to better match its semantics. We can
have a "Java-like DOM" binding for all languages. But that is bad for web
developers, and it is not the agreement we reached between w3c and Ecma folks
trying to collaborate here.

The right argument to have IMHO is not some imponderable one about whether we
should chip away at JS semantics in full, demanding proofs of negatives before
restoring acccessor support. Instead, I contend we should consider exactly what
properties (integrity, availability) to uphold and examine the threads posed by
getters and setters.

If we find, as I believe, that we can uphold these properties without too much
spec complexity and any loss of "JS generality", then we should stay the course
of making WebIDL bindings in JS more "as if the method were written in JS".

/be

[*] It's true with ES5 one could write a method that interrogates an object
"keyword parameter set" for all of its property names and skips accessors, but
this is not done, either by JS libraries or by any built-in in ES5.

-- 
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, 8 March 2011 04:01:23 UTC