On Mon, Jul 22, 2013 at 12:42 PM, Brendan Eich <[email protected]> wrote: > Tab Atkins Jr. wrote: >> On Sun, Jul 21, 2013 at 9:25 PM, Brendan Eich<[email protected]> wrote: >>> Tab Atkins Jr. wrote: >>>> In reality, only the web-exposed parts are, >>> >>> What is not web-exposed here, pray tell? >> >> The parser itself. Only the results of the parser are, in terms of >> observable program behavior and presence/absence of syntax errors. > > This is irrelevant, since the change you are proposing is a > compatibility-breaking one, even though parse trees are not yet reflectable.
Of course. But Rick's argument against was justifying itself on the parser, not expectation of web-dependence on the results. Just trying to point out the correct thing to be arguing about. >>>> and >>>> then only the parts that the web actually depends on. >>> >>> This is the part we can't determine. "The web" is not just the >>> Google-indexable (by what user agent?) part, but paywalled and intranet >>> content as well. I've written before that finding true positives helps >>> reject a proposed incompatible change, but finding no positives does not >>> prove that we can make the change. >>> >>> Furthermore, the first browser to roll the dice and face breakage loses, >>> making implementors generally unwilling to take even likely-small risks. >>> This browser Prisoner's Dilemma can be helped by cooperation, e.g., among >>> TC39ers, but even then only for a big enough payoff. See the typeof null >>> == >>> "null" attempt early in ES6 development for an example. >> >> Preaching to the choir, buddy - I've been standardsing for quite a >> while too. > > So why were you preaching at Rick? I didn't want to reply, but at some point > the one-sided arguing got to be too much. > > Look, you're proposing an incompatible change, akin to typeof null's result > change. It doesn't matter why people might write code you'd break, it > matters how much code exists. That's an empirical question. Exhorting people > here does nothing but annoy some of us. You've lost track of who's suggesting what. I'm not suggesting anything - it was a proposal by Andy. I've brought up problems with the suggestion in the thread. This side-thread is about the fact that Rick shot down the idea not based on possible breakage, but on a pure "this would be a spec change" argument, which is not a valid argument in and of itself against a change. (It points to the possibility of web-compat issues which would prevent the change, but does not itself prevent anything.) I just wanted to avoid letting a precedent stand of something being rejected purely on spec-conflict grounds. I didn't intend for the point to get confused like this. ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
