Proposed change to typeof
On Nov 5, 2008, at 1:42 PM, David-Sarah Hopwood wrote:
Of course not. In this case we were talking about a case in which IE and Opera do not implement an extension, and follow the existing
standard more closely in their implementations of 'typeof'.
Yes, I know, but the particular case involving an extension in two
browsers out of four does not prove the lack of web-breaking.
Why would anyone use callable regexps in the non-IE path of an "isIE" test, but not in the IE path? To do that they would have to:
You haven't read a lot of web JS, I can tell :-/.
You've already heard from Maciej and me on this: we would not remove
callable regexps without a lot of testing, more than the typeof issue
requires (since we've been through release cycles with typeof changes).
Brendan Eich wrote:
On Nov 5, 2008, at 1:42 PM, David-Sarah Hopwood wrote:
Of course not. In this case we were talking about a case in which IE and Opera do not implement an extension, and follow the existing standard more closely in their implementations of 'typeof'.
Yes, I know, but the particular case involving an extension in two browsers out of four does not prove the lack of web-breaking.
Why not? If a particular site already breaks on IE and Opera, why should we be overly concerned if it also breaks on a future version of Firefox?
When developers write JS that isn't portable between browsers because it ignores standards, there's no reason why they should have any confidence that it will be portable to future versions of the same browser, either.
On Nov 5, 2008, at 5:40 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Nov 5, 2008, at 1:42 PM, David-Sarah Hopwood wrote:
Of course not. In this case we were talking about a case in which IE and Opera do not implement an extension, and follow the existing
standard more closely in their implementations of 'typeof'.Yes, I know, but the particular case involving an extension in two browsers out of four does not prove the lack of web-breaking.
Why not? If a particular site already breaks on IE and Opera, why
should we be overly concerned if it also breaks on a future version of
Firefox?
We are going in circles. I pointed to user-agent forked JS web
content, which could work in all four major browsers. There is a lot
of user-agent forked web content, mostly to cope with DOM differences
but also sometimes JS/JScript differences -- including unknown,
unintended JS vs. JScript dependencies hiding as latent bugs in the
DOM-forked alternatives.
"The web" is not a unitary function that breaks (or not) on a given
pure-JS input, ignoring the browser's identity. The browser and the
user-agent sniffing in the input matter.
On Nov 5, 2008, at 5:40 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Nov 5, 2008, at 1:42 PM, David-Sarah Hopwood wrote:
Of course not. In this case we were talking about a case in which IE and Opera do not implement an extension, and follow the existing
standard more closely in their implementations of 'typeof'.Yes, I know, but the particular case involving an extension in two browsers out of four does not prove the lack of web-breaking.
Why not? If a particular site already breaks on IE and Opera, why
should we be overly concerned if it also breaks on a future version of
Firefox?
Sites often code dual code paths, IE and non-IE. Often the non-IE path
is tested only in Firefox, or if we are lucky, in Safari too. Thus, it
is entirely plausible for an extension that is in Safari and Firefox
but not IE or Opera to actually matter for Web compatibility. In the
case of this particular extension, that seems relatively unlikely, but
I wouldn't bet my market share on it without doing significant testing.
More generally, it is impossible to have good judgment about what kind
of changes could be Web-breaking without having significant long-term
exposure to the bug database of a major browser engine. Since there
are two that are open source with public bug databases, anyone who is
willing and able to invest the time can gain such experience. Likely
what you would learn is that almost anything a Web developer could
do, no matter how seemingly stupid, is inevitably done by some site
somewhere.
When developers write JS that isn't portable between browsers
because it ignores standards, there's no reason why they should have any
confidence that it will be portable to future versions of the same browser,
either.
When sites break, users blame the browser, even if it is in some
abstract sense the site's fault. Typically users react not by
complaining to the site for using unportable code, but by complaining
to the browser vendor or switching browsers. This is even more the
case when a site that worked in an earlier version of the browser
fails in a later version.
Like it or not, these are the dynamics of the browser market.
ES3.1 is premised on accepting these dynamics, being originally
conceived as "ES3 + reality".
, Maciej
On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak <mjs at apple.com> wrote:
ES3.1 is premised on accepting these dynamics, being originally conceived as "ES3 + reality".
I have heard this repeated many times. I'm not sure where this comes from, but that has never been the sole conception of ES3.1 by the people advocating it or working on it. One can examine the history of < es3.1:es3.1_goals> to see the
timeline of ES3.1 goals. In particular, Pratap's text as of April 2007 -- long before I got involved -- reads:
- Improve implementation conformance by rewriting the specification to improve its rigor and clarity, and by correcting known points of ambiguity or under specification.
- Add commonly implemented and used extensions to the standard (specifically most JavaScript 1.6 and 1.7 features)
- Incorporate high leverage incremental extensions that support current usage experience and best practices
- Adopt low impact language changes that correct well known performance or reliability issues
- Identify problematic features to be designated as deprecated
- Maximize both forward and backwards compatibility between ES3 and ES3.1 as well as between ES3.1 and ES4.
That's a lot more than "ES3+Reality".
By February 2008, our goals were even more distinct from just ES3+Reality:
- Browser implementation unification: Consider adopting features that are already implemented in 3 of the 4 browser brands, or that are deployed in 3 out 4 user computers and reduce cross browser incompatibilities.
- ES3.1 shall improve the language to benefit casual developers by reducing confusing or troublesome constructs.
- ES3.1 shall improve the language to benefit major websites by reducing confusing or troublesome constructs.
- ES4 shall become a superset of ES3.1.
- ES3.1 shall be a friendly base for a secure subset.
- ES3.1 shall attempt to correct errors in ES3.
- ES3.1 new features shall require concrete demonstrations.
- ES3.1 may deprecate (or eliminate with opt-in) features that are problematic for performance, security, or reliability.
- ES3.1 shall provide virtualizability, allowing for host object emulation.
So can we please now put this rumor to rest? Thanks.
On Nov 5, 2008, at 7:52 PM, Mark S. Miller wrote:
On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak <mjs at apple.com>
wrote:ES3.1 is premised on accepting these dynamics, being originally
conceived as "ES3 + reality".I have heard this repeated many times.
I heard it first with you and Maciej in the room, at Google, at the
January 2008 TC39 meeting. I'm not sure who said it, but it was part
of a committee-wide conversation about avoiding mission creep --
something I specifically recall you said you would help the committee
strive to avoid.
The July deadline of that era, the choice of specification based on
ES3's untestable pseudo-code and prose, and the minor version number
all make sense only in a limited-scope iteration on an "ES3 +reality"
mission.
Since January, the mission may have changed a bit but it cannot be as
open-ended as the goal statements you cite.
- Add commonly implemented and used extensions to the standard
(specifically most JavaScript 1.6 and 1.7 features)
I think these are what Maciej and others at that January meeting meant
by "reality".
Nevertheless, you're right that 3.1 did grow beyond that. The big
growth spurt, starting in April, was in the Object meta-programming
methods. I remember talking to Allen about these at the mid-April
Newton ES4 WG meeting.
The Object meta-programming suite is good stuff, necessary for getters
and setters and a lot more, including aspects of Harmony. No argument:
this goes beyond "ES3 + reality" -- but it happend after that January
meeting where the phrase was used.
I'm afraid the goals you list are too vague to shed light on what's in
ES3.1 vs. out (out meaning for ES4 then, for Harmony since the
summer). Too much broad motherhood and apple pie, too little to help
make crucial in vs. out decisions.
How about this concrete list instead? If we number the goals, we could
stick their numbers next to each letter-bulleted feature and probably
then revise the goals to be tighter:
A. ES3 B. Errata from Mozilla, others C. Indirect eval agreements and similar D. Array extras (map, filter, etc.) E. JSON F. getters and setters G. Object.* meta-programming H. Strict mode I. Decimal
So while A-F are indeed "ES3 + reality", I agree that G and H add
enough that we can give "ES3 + reality" a rest. :-)
I am still unsure of whether item I fits in ES3.1, but Decimal is
being implemented in SpiderMonkey, which is the right order of work
for adding something like decimal arithmetic in my book:
implementation for user testing, concurrent or later spec drafting,
then spec finalization.
Given the progress Sam has made, Decimal may have more available/open-
source implementation and large-scale user experience than anything
else truly new (i.e., not JSON) in ES3.1. It will be hard for the
committee to reject if that happens!
Let me know if I've overlooked comparable items.
Having agreed to avoid "ES3 + reality", I have to say: broad and high- level goals do not help scope ES3.1.
More, I think Maciej is on target in stressing the dynamics of web
interoperation and browser competition, which Neil Mix wrote about
previously, because those dynamics override many other considerations
that might be seen as flowing from the (too-)high-level goals.
And time is still of the essence, which must mean no open-ended
process of enlargement -- rather, concentrated work on a same-size or
even-smaller-than-current-draft spec.
On Nov 5, 2008, at 7:52 PM, Mark S. Miller wrote:
On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak <mjs at apple.com>
wrote:ES3.1 is premised on accepting these dynamics, being originally
conceived as "ES3 + reality".I have heard this repeated many times. I'm not sure where this comes
from, but that has never been the sole conception of ES3.1 by the
people advocating it or working on it.
I'm not sure what your goal is in establishing disagreement. Note, I
said "originally conceived", meaning I accept that it has now expanded
to encompass a limited set of brand new features as well. My point was
to stress that reality is and always has been a goal, not that other
things aren't. I hope you do not mean to deny that reality is a goal
at all.
Like Brendan, I recall ES3.1 advocates using this phrasing at the
January 2008 meeting. At the time, much less was on the table in terms
of object model extensions, and IBM's vote had not yet been bought by
adding decimal. That doesn't mean the scope can't change. After all,
we are all ES3.1 advocates now, and we all agree to some modest
extensions.
So can we please now put this rumor to rest? Thanks.
I heard this phrasing first hand from some of the core ES3.1 people at
the time. I don't think it is rumor-mongering to repeat it,
particularly in the past tense. If the phrase did not really line up
with the goals of the core ES3.1 group even then, the fault is not mine.
, Maciej
On Thu, Nov 6, 2008 at 6:46 AM, Maciej Stachowiak <mjs at apple.com> wrote:
On Nov 5, 2008, at 7:52 PM, Mark S. Miller wrote:
On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak <mjs at apple.com> wrote:
ES3.1 is premised on accepting these dynamics, being originally conceived as "ES3 + reality".
I have heard this repeated many times. I'm not sure where this comes from, but that has never been the sole conception of ES3.1 by the people advocating it or working on it.
I'm not sure what your goal is in establishing disagreement. Note, I said "originally conceived", meaning I accept that it has now expanded to encompass a limited set of brand new features as well.
My point was only to straighten out the history. Oft repeated statements, not corrected, tend to become the history of record. I do not mean to imply there is any current disagreement on the nature, goals, or importance of ES3.1. In fact, I am ecstatic that we have no such disagreements.
On the history, ES3+Reality was and is certainly one of the important goals of ES3.1. I had also not meant to imply otherwise. I am trying to correct the impression I've heard repeated many times that ES3.1 was originally conceived as "only ES3+Reality". If that isn't what you meant, my apologies for directing this correction at you.
On Nov 6, 2008, at 7:26 AM, Mark S. Miller wrote:
On Thu, Nov 6, 2008 at 6:46 AM, Maciej Stachowiak <mjs at apple.com>
wrote: On Nov 5, 2008, at 7:52 PM, Mark S. Miller wrote:On Wed, Nov 5, 2008 at 7:14 PM, Maciej Stachowiak <mjs at apple.com>
wrote:ES3.1 is premised on accepting these dynamics, being originally
conceived as "ES3 + reality".I have heard this repeated many times. I'm not sure where this
comes from, but that has never been the sole conception of ES3.1 by
the people advocating it or working on it.I'm not sure what your goal is in establishing disagreement. Note, I
said "originally conceived", meaning I accept that it has now
expanded to encompass a limited set of brand new features as well.My point was only to straighten out the history. Oft repeated
statements, not corrected, tend to become the history of record. I
do not mean to imply there is any current disagreement on the
nature, goals, or importance of ES3.1. In fact, I am ecstatic that
we have no such disagreements.On the history, ES3+Reality was and is certainly one of the
important goals of ES3.1. I had also not meant to imply otherwise. I
am trying to correct the impression I've heard repeated many times
that ES3.1 was originally conceived as "only ES3+Reality". If that
isn't what you meant, my apologies for directing this correction at
you.
As far as I know, I first heard the phrase from ES3.1 proponents. I
have not generally repeated it because it did not sound like a very
useful statement of principles, except in this case to establish that
reality is an important goal. I do not know what back-in-the-day ES3.1
proponents meant by the phrase, or whether they meant "only". My
intention was only to quote, not to establish the true meaning of the
phrase, whether it implied "only", or whether it was in fact accurate
as a catchphrase. It is my best recollection that this phrase was
coined in advocacy of ES3.1.
, Maciej
Here is the end-game plan that I envision taking into account my perception of the current state of the draft:
- Latter today, a review draft for the Kona meeting will be published. This draft is intended to be technically complete but does internally identify various unresolved technical issues. In addition, we (everybody involved with ES3.1) should strive to identify any additional unresolved technical issues prior to the Kona meeting.
- At Kona, the goal is to resolve all outstanding technical issues and reach consensus that with those resolutions we have concluded the technical "feature" design and revision of ES3.1
- Within two weeks after the end of the Kona meeting, a final technical draft that incorporates the Kona decisions is published. The intent is for this to be the frozen technical specification that is the basis of trial implementations and interoperability testing.
- Before the end of December TC-39, meeting electronically, accepts the post Kona draft as the frozen specification.
- Test implementation work begins (if it hasn't already, the results of the Kona meeting should actually be sufficient to start such work)
- The frozen December draft will still have non-technical editorial issues such as formatting, styling, spelling, etc. It will probably also have some technical specification issues where the technical intent has been decided (at Kona or previously) but where the actual specification language is unclear, ambiguous, or otherwise problematic. In additional, it is reasonable to expect that trial implementation will uncover some additional specification issues.
- During January and February work will continue on polishing the specification to resolve all such editorial and specification issues.
- No technical changes will be made to the feature content of the specification unless they are necessary to resolve issues identified by trial implementations/interoperability testing.
- Final publication quality draft and interoperability testing results are reviewed (and hopefully approved) at March TC-39 meeting.
- The proposed standard advances through the CC to the GA for consideration at the June GA meeting.
Thoughts??
Allen From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of OpenStrat at aol.com Sent: Wednesday, November 05, 2008 10:42 PM To: brendan at mozilla.com; erights at google.com Cc: es3.x-discuss at mozilla.org; es-discuss at mozilla.org Subject: Re: Proposed change to typeof
Brendan Eich wrote:
Of course not. In this case we were talking about a case in which IE and Opera do not implement an extension, and follow the existing standard more closely in their implementations of 'typeof'.
"Breaking the web" is obviously only one criterion among many in deciding whether to standardize or prohibit an extension, and I did not say anything about those other criteria in the sentence you responded to.
Why would anyone use callable regexps in the non-IE path of an "isIE" test, but not in the IE path? To do that they would have to: