On Nov 10, 2007 9:10 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Nov 10, 2007, at 8:00 PM, Mark Miller wrote:
[out of order]
>> * The intersection of ES3 and ES4 must be approximately as pleasant a
>> programming language as ES3 currently is.
>
> No, the intersection is "ES3 + reality" + two (known) true
> incompatibilities. "ES3 + reality" means the ES3 spec was not followed (for
> variously better and worse reasons) and the de-jure standard needs to be
> adjusted based on what browsers actually do that web developers actually
> count on.
>
> "ES3 + reality" does not mean every last JScript bug, of course, especially
> since many have not been emulated by other browsers' implementations. It
> does not mean over-specifying what should remain implementation-dependent
> (e.g., Date.parse as implemented in various browsers). It does mean some
> case-by-case greater specification where browsers differ in ways that hurt
> interoperation.
Yes, I appreciate the point about reality. And well put!
I will use "ES3R" below to mean "ES3 + reality".
>> * To prevent these new keywords breaking ES3 compatibility, these
>> keywords are only recognized when a version attribute on the script
>> tag says the script is in ES4.
>
> This has happened before, FYI -- from ES1-3 under various vendor
> experimental MIME types or script language attribute values -- and it
> continued after ES3 with (at least) JS1.6 and 1.7
> (application/javascript;version=1.7).
Yes, good. Specifically the overview doc states:
# The mechanism that supplies the dialect information will depend on the
# environment. In a web browser the information comes from the MIME
type of the
# script or from a version parameter on the SCRIPT tag in the document.14 New
# web pages that choose to use ES4 will have to specify the dialect.
It seems we are agreeing on what this text means so far.
>> * This attribute does create two languages in effect, but not two
>> language implementations, and therefore does not violate the size
>> constraint.
>
> Writing "this attribute does create two languages in effect" seems to
> conflate compatible successive versions with one a subset of the other, and
> two completely separate programming languages. I'm not sure what it means,
> so it's hard to tell what its significance is in the bulleted list. I'm
> probably missing something obvious -- little help?
I'm simply observing that the version switch explained above changes
what language is being recognized. With the switch off (or set to ES3
or ES3R), the new keywords aren't recognized as keywords. With the
switch set to ES4, the new keywords are recognized as keywords. What I
don't understand is: Why can't this switch change other aspects of the
language being recognized, so long as this doesn't result in a larger
implementation? For *example*, if one of the purposes of ES4 can be
served by removing a keyword such as "with", can we consider having
this same switch (set to ES4) remove it?
I'm using "with" here only as an example, to try to understand the
nature of the compatibility constraints on the ES4 process.
>> * The ES4 language (as recognized with the version attribute) and the
>> ES3 language must be able to smoothly share an implementation.
>
> Yes.
Good.
>> * Whenever the goals of ES4 can be achieved by removing unneeded
>> features from ES3 (e.g. "with"), rather than adding features, the shared
>> implementation can smaller, and therefore even better for small
>> devices.
>
> This does not follow if the goals of ES4 include backward compatibility
> (they do), since the web depends all over the place on "with". So the
> (common) implementation must support ES3 "with", and adding runtime
> versioning to make "with" an error in ES4 just adds code (a tiny amount for
> the version check) and makes migration harder (more important that the
> miniscule version check overhead). See also reformed with.
Let's say, hypothetically, that by removing "with" from ES4 (with the
version switch) we could avoid adding something else to ES4. Let's say
that the feature we could avoid adding is larger than the code needed
to switch "with" on and off. Would the removal of "with" from ES4 then
be an option? If not, what compatibility issue does it raise that
isn't raised by the addition of the other keywords?
>> Does this make sense so far? Am I missing something?
>
> You wrote about design constraints, but also talked about goals of ES4
> without listing them. The two are not the same. [...]
Indeed. That's exactly why I didn't list them. I want to understand
the design constraints first before making proposals regarding goals.
> Backward compatibility is not simple or static -- it is fuzzy and it changes
> as the web changes. There's hope, but the time scales are long and you can't
> force change by removing things from browsers. You have to see competitors
> take the plunge, and even then you must face down the rear guard (e.g.,
> removing gopher from Firefox).
Also well put.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
