javascript 2.0 release???

[yuan]

hello,all.
now ,did the javascript 2.0 and ECMA 4th be release????
can who tell me!!!
thanks

[Julian Turner]

yuan wrote:

hello,all.
now ,did the javascript 2.0 and ECMA 4th be release????
can who tell me!!!
thanks

AFAIK, not yet.

See the blog from the man himself:-

<URL:http://weblogs.mozillazine.org/roadmap/archives/2005_10.html>

Julian

[VK]

yuan wrote:

hello,all.
now ,did the javascript 2.0 and ECMA 4th be release????
can who tell me!!!

Easy, man, easy... :-) The God did not die yet :-)

But yes, with FF 1.5 and upcoming IE 7.0 - ECMA 262 looses another
good part of its practical value. It's like a theoretical physics book
now: you cannot use it to build a nuclear power plant but it is still
useful if you want to know how the things are (should be) ticking at
the ground zero.

[Thomas 'PointedEars' Lahn]

VK wrote:

But yes, with FF 1.5 and upcoming IE 7.0 - ECMA 262 looses another
good part of its practical value. [...]

It does not. AFAIS, JavaScript 1.6 as implemented in FF 1.5 is fully
compatible with ECMAScript 3. ECMAScript states that conforming
implementations may extend the language it as long as they support
what is specified:

<cite
src="http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf>

2 Conformance

A conforming implementation of ECMAScript must provide and support all the
types, properties, functions, and program syntax and semantics described in
this specification.

[...]
A conforming implementation of ECMAScript is permitted to provide additional
types, values, objects, properties, and functions beyond those described in
this specification. In particular, a conforming implementation of
ECMAScript is permitted to provide properties not described in this
specification, and values for those properties, for objects that are
described in this specification.

A conforming implementation of ECMAScript is permitted to support program
and regular expression syntax not described in this specification. In
particular, a conforming implementation of ECMAScript is permitted to
support program syntax that makes use of the ?future reserved words? listed
in 7.5.3 of this specification.

</cite>

JavaScript 1.6 and JScript 5.6+ do both. JavaScript 1.6 adds additional
methods to Array objects (i.e. the Array prototype object) and extends
both the Array and the String object with those methods to allow generics.

<URL:http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6>

JScript 5.6 (IE 6) and .NET (.NET 1.0) also extend the specified language
features:

<URL:http://msdn.microsoft.com/library/en-us/script56/html/js56jsgrpnonecmafeatures.asp>
<URL:http://msdn.microsoft.com/library/en-us/jscript7/html/jsgrpnonecmafeatures.asp>

In what regard is _upcoming_ IE 7 relevant here?
PointedEars

[RobG]

VK wrote:

yuan wrote:

hello,all.
now ,did the javascript 2.0 and ECMA 4th be release????
can who tell me!!!

Easy, man, easy... :-) The God did not die yet :-)

But yes, with FF 1.5 and upcoming IE 7.0 - ECMA 262 looses another
good part of its practical value.

That's ridiculous. The latest version of JavaScript is 1.6, which is
compliant with ECMAScript Edition 3 plus E4X (ECMAScript
for XML or ECMA 357). That doesn't in any way reduce the
importance of ECMAScript Language Ed3.

I think you are getting DOM and proprietary/platform-dependent
interfaces and confused with the underlying script language specification.
--
Rob

[Randy Webb]

VK said the following on 11/30/2005 3:51 AM:

yuan wrote:

hello,all.
now ,did the javascript 2.0 and ECMA 4th be release????
can who tell me!!!

Easy, man, easy... :-) The God did not die yet :-)

But yes, with FF 1.5 and upcoming IE 7.0 - ECMA 262 looses another
good part of its practical value. It's like a theoretical physics book
now: you cannot use it to build a nuclear power plant but it is still
useful if you want to know how the things are (should be) ticking at
the ground zero.

Wanting to know how the things "should be" ticking instead of how things
really are ticking has always been the only thing I found ECMA 262 good
for. The release of a newer setter of browsers that may or may not make
it obsolete doesn't matter. It is still only a theory of how things
should be instead of a true indication of how things really are.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

RobG wrote:

That's ridiculous. The latest version of JavaScript is 1.6, which is
compliant with ECMAScript Edition 3 plus E4X (ECMAScript
for XML or ECMA 357). That doesn't in any way reduce the
importance of ECMAScript Language Ed3.

I think you are getting DOM and proprietary/platform-dependent
interfaces and confused with the underlying script language specification.

No, I'm trying to resolve a confusion between "ECMAScript language" and
"ECMAScript-compliant" while *some people* are tending to place an
equal mark between them.

There were no browsers so far implementing ECMAScript language: means
everything written in ECMA 262 and nothing less and *nothing more*. And
now it is too late I guess to expect that such implemetation will ever
appear (unless someone decides to make a really retarded browser). So
ECMA 262 will stay forever as an abstract model description.

At the same time web solutions are targeted not to some imaginary
browser, but to the very real ones. And if you need to make a
functional and effective modern solution you have to deal with the
actual language implementation and *description*. This is the only way
if you do the job for money and not for some credo statement.

The only weak excuse to stay withing ECMA exclusively would be to
support (for sport or for some personal credo) all ever existed
browsers with JavaScript/JScript support. *But* it would be such exuse
if and only if ECMA 262 features would be guaranteed on each and every
browser produced at least since December 1999. But it is not true:
until now we have some ugly mutants appearing (sometimes under loud
brands) which barely care JavaScript 1.0

So yes again: if you wondering what string format you should expect
from JavaScript, you read ECMA. But if you need to build AJAX interface
or file management system - you have to read producers' documentation.

Do not take me wrong: ECMA 262 is still should be known, as an
electrician should know the Ohm's law. But besides that the electrician
should know how to handle wires and contacts?

[Thomas 'PointedEars' Lahn]

Randy Webb wrote:

Wanting to know how the things "should be" ticking instead of how things
really are ticking has always been the only thing I found ECMA 262 good
for. The release of a newer setter of browsers that may or may not make
it obsolete doesn't matter. It is still only a theory of how things
should be instead of a true indication of how things really are.

You are absolutely wrong. ECMAScript is specified to be extendable by
conforming implementations and so far nothing else has been proven about
implementations that call themselves ECMAScript compliant.
PointedEars

[Thomas 'PointedEars' Lahn]

VK wrote:

[...] I'm trying to resolve a confusion between "ECMAScript language"
and "ECMAScript-compliant" while *some people* are tending to place an
equal mark between them.
You have yet to understand that ECMAScript is by design like a
blueprint that allows conforming implementations of it to extend it.
There were no browsers so far implementing ECMAScript language: means
everything written in ECMA 262 and nothing less and *nothing more*.
So far that was not expected. ECMAScript Edition 1 is based upon
JavaScript 1.1 and JScript 1.0 which already had more features than
the specified ones which is why the "extensible" feature was already
specified in that first edition. In order to provide for backwards
compatibility among themselves, and in order for other browser vendors
to keep up with the competion against NN and IE, inevitably they had
to support features that were not specified in ECMAScript editions.

However, from <URL:http://www.opera.com/docs/specs/js/ecma/> ISTM now
that Opera's language implementation is pretty close to qualify as
"ECMA-262 (Edition 3) and nothing less and nothing more", maybe even
matching that. Lasse?
And now it is too late I guess to expect that such implemetation will ever
appear (unless someone decides to make a really retarded browser). So
ECMA 262 will stay forever as an abstract model description.

No, you have not understood the role ECMAScript played in the history
of client-side scripting and its repercussions on today's conforming
language implementations. No surprise here, though, since it already
had become clear that you never read any edition of it (thoroughly).
PointedEars

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

However, from <URL:http://www.opera.com/docs/specs/js/ecma/> ISTM now
that Opera's language implementation is pretty close to qualify as
"ECMA-262 (Edition 3) and nothing less and nothing more", maybe even
matching that. Lasse?

Well, that page sums it up pretty well. There is one extra method on a
language object (RegExp.prototype.compile), and a few extra global
functions (anchor, link, etc.), but apart from that, all the
implemented functions *in that list* are from the ECMAScript standard.

There is still the odd bug in the implementation, but I don't know of
any that you would hit in normal use. (Example:

var a = [,,,,,,,1];
alert([0 in a,1 in a,2 in a,3 in a,4 in a,5 in a,6 in a,7 in a]);
// alerts false,false,false,false,false,false,false,true.
a.sort();
alert([0 in a,1 in a,2 in a,3 in a,4 in a,5 in a,6 in a,7 in a]);
// should alert: true,false,false,false,false,false,false,false
// alerts: true,true,true,true,true,true,true,false

There seems to have to be at least 8 elements in the array for the bug
to appear, and the order is also important. Obscure indeed :)

Still, the implementation of the core language isn't really that
interesting. It's the DOM that, i.e., the runtime environment, that
really defines what you can do with Javascript, and there the browsers
still differ quite a lot. DOM 0 really is an extension to ECMAScript,
in that it extends the global object with extra properties (like
"document"), so no browser will ever be pure ECMAScript.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

[...] DOM 0 really is an extension to ECMAScript, in that it extends the
global object with extra properties (like "document"), so no browser will
ever be pure ECMAScript.

1. How can you be so sure that `document' is a property of the
Global Object?

2. I was talking about the ECMAScript language implementations,
not about the DOM.
PointedEars

[John G Harris]

In article <11*********************@g49g2000cwa.googlegroups. com>, VK
<sc**********@yahoo.com> writes

<snip>

But yes, with FF 1.5 and upcoming IE 7.0 - ECMA 262 looses another
good part of its practical value.

<snip>

Look up 'looses' and 'loses' in a dictionary - you'll find you've said
something true about ECMA 262 instead of what you wanted to say.

John
--
John Harris

[John G Harris]

In article <11*********************@g44g2000cwa.googlegroups. com>, VK
<sc**********@yahoo.com> writes

<snip>

There were no browsers so far implementing ECMAScript language: means
everything written in ECMA 262 and nothing less and *nothing more*. And
now it is too late I guess to expect that such implemetation will ever
appear (unless someone decides to make a really retarded browser). So
ECMA 262 will stay forever as an abstract model description.

<snip>

Does ECMA 262 say what

var x = 5;

does? Yes. Does ECMA 262 say what

alert(x);

does? No. You're so clever, tell us what alert should do inside a web
server. Send an e-mail to sc**********@yahoo.com ?

John
--
John Harris

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Lasse Reichstein Nielsen wrote:

[...] DOM 0 really is an extension to ECMAScript, in that it extends the
global object with extra properties (like "document"), so no browser will
ever be pure ECMAScript.
1. How can you be so sure that `document' is a property of the
Global Object?

(function () { alert("document" in this); })();
2. I was talking about the ECMAScript language implementations,
not about the DOM.

But what is an ECMAScript implementation?

For Opera, I can't distinguish the code implementing the ECMAScript
language from the code implementing the runtime host environment that
it runs in, so I can't say that it is ECMAScript and nothing more.

Spidermonkey is an implementation of ECMAScript and more. I haven't
read the code, so I can't say whether this "more" (like __proto__ and
getter/setter hooks) is part of the ECMAScript implementation, or in
addition to a pure ECMAScript implementation.
I'm sure that, given time, I would be able to remove these extra
features, and have a "pure" ECMAScript implementation ... but that was
the one that was already there, so was the ECMAScript implementation
already pure, and the additions separate from it?

So, I guess my point is that a running ECMAScript implementation is
never "pure", because the runtime environment cannot be separated from
it.

Only a separate implementation, e.g., where you have the code, can
ever be "ECMAScript and nothing but" ... but if it is more, does it
just mean that there is a pure ECMAScript interpreter in it somewhere?

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[VK]

Lasse Reichstein Nielsen wrote:

Only a separate implementation, e.g., where you have the code, can
ever be "ECMAScript and nothing but" ... but if it is more, does it
just mean that there is a pure ECMAScript interpreter in it somewhere?

As John G Harris pointed in this thread:

ECMA tried so hard to keep the description away from any host
environment that they have created an unique "language" wich:
1) doesn't have any means to accept any input
2) doesn't have any means to output results

ECMA 262 per se is a totally enclosed system "out of time and space".
This alone would be enough to say that "ECMAScript Language" is a wrong
term. ECMAScript is an abstract model description which *have* to be
extended to become a programming language.

[Thomas 'PointedEars' Lahn]

VK wrote:

Lasse Reichstein Nielsen wrote:

Only a separate implementation, e.g., where you have the code, can
ever be "ECMAScript and nothing but" ... but if it is more, does it
just mean that there is a pure ECMAScript interpreter in it somewhere?
As John G Harris pointed in this thread:

ECMA tried so hard to keep the description away from any host
environment that they have created an unique "language" wich:
1) doesn't have any means to accept any input
2) doesn't have any means to output results

ECMA 262 per se is a totally enclosed system "out of time and space".

Quite the contrary.
This alone would be enough to say that "ECMAScript Language" is a wrong
term. ECMAScript is an abstract model description which *have* to be
extended to become a programming language.

To be able to receive user input and to be able to generate output to a
device are not requirements for a programming language. Your logic is,
again, flawed.
PointedEars

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 11/30/2005 7:45 AM:

Randy Webb wrote:

Wanting to know how the things "should be" ticking instead of how things
really are ticking has always been the only thing I found ECMA 262 good
for. The release of a newer setter of browsers that may or may not make
it obsolete doesn't matter. It is still only a theory of how things
should be instead of a true indication of how things really are.

You are absolutely wrong.

Am I? 10+ years experience tell me I am not wrong. But rather have
proven to me that I am right.
ECMAScript is specified to be extendable by conforming implementations and
so far nothing else has been proven about implementations that call themselves
ECMAScript compliant.

And I said nothing about the language being extended. I said that ECMA
is a good Theory about how things should be, not a reflection of how
things really are. If every UA followed the Specs to the letter, then
99% of questions could be answered with a "RTFM" but they do not follow
it to the letter so it can't be an indication of how things really are
but rather a Theory on how things should be.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Thomas 'PointedEars' Lahn]

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 11/30/2005 7:45 AM:

Randy Webb wrote:

Wanting to know how the things "should be" ticking instead of how things
really are ticking has always been the only thing I found ECMA 262 good
for. The release of a newer setter of browsers that may or may not make
it obsolete doesn't matter. It is still only a theory of how things
should be instead of a true indication of how things really are.

You are absolutely wrong.

Am I? 10+ years experience tell me I am not wrong. But rather have
proven to me that I am right.

Experience is defined by its quality; its quality is not only defined by its
duration.

ECMAScript is specified to be extendable by conforming implementations
and so far nothing else has been proven about implementations that call
themselves ECMAScript compliant.

And I said nothing about the language being extended. I said that ECMA
is a good Theory about how things should be, not a reflection of how
things really are. If every UA followed the Specs to the letter, then
99% of questions could be answered with a "RTFM" but they do not follow
it to the letter so it can't be an indication of how things really are
but rather a Theory on how things should be.

You have yet to prove that there is a significant number of browsers that
do not support a significant number of ECMAScript features in the way they
are specified.

You will not be able to prove that.
PointedEars

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 12/1/2005 7:10 AM:

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 11/30/2005 7:45 AM:

Randy Webb wrote:

Wanting to know how the things "should be" ticking instead of how things
really are ticking has always been the only thing I found ECMA 262 good
for. The release of a newer setter of browsers that may or may not make
it obsolete doesn't matter. It is still only a theory of how things
should be instead of a true indication of how things really are.

You are absolutely wrong.

Am I? 10+ years experience tell me I am not wrong. But rather have
proven to me that I am right.

Experience is defined by its quality; its quality is not only defined by its
duration.

Based on the money I get paid for my work and its quality, the quality
is there. I just don't deal with Theory, I leave that to others. I
prefer to deal with the Reality side of it.

ECMAScript is specified to be extendable by conforming implementations
and so far nothing else has been proven about implementations that call
themselves ECMAScript compliant.

And I said nothing about the language being extended. I said that ECMA
is a good Theory about how things should be, not a reflection of how
things really are. If every UA followed the Specs to the letter, then
99% of questions could be answered with a "RTFM" but they do not follow
it to the letter so it can't be an indication of how things really are
but rather a Theory on how things should be.

You have yet to prove that there is a significant number of browsers that
do not support a significant number of ECMAScript features in the way they
are specified.

You will not be able to prove that.

In the same way that you will not be able to prove that there is a
significant number of browsers that support a significant number of
ECMAScript features in the way they are specified.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Lasse Reichstein Nielsen]

Randy Webb <Hi************@aol.com> writes:

And I said nothing about the language being extended. I said that ECMA
is a good Theory about how things should be, not a reflection of how
things really are. If every UA followed the Specs to the letter, then
99% of questions could be answered with a "RTFM" but they do not
follow it to the letter so it can't be an indication of how things
really are but rather a Theory on how things should be.

99% of questions about ECMAScript can be answered by a RTFM (although
a more helpful response is preferable, because TFM isn't very easy to
read).

It's just that most questions in this group is not about ECMAScript
but about DOM and its ECMAScript binding.

Questions about, e.g., clusures, the "this" operator, and automatic
type conversion (1+"1" problem) are all answerable by pointing to the
specification, and I have yet to meet an implementation that doesn't
do it according to spec.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[John G Harris]

In article <11**********************@g44g2000cwa.googlegroups .com>, VK
<sc**********@yahoo.com> writes

<snip>

As John G Harris pointed in this thread:

ECMA tried so hard to keep the description away from any host
environment
I said that, and I said it because

a) it's true, and

b) that was the right thing for the ECMA committee to do.
that they have created an unique "language" wich:
1) doesn't have any means to accept any input
2) doesn't have any means to output results

ECMA 262 per se is a totally enclosed system "out of time and space".
This alone would be enough to say that "ECMAScript Language" is a wrong
term. ECMAScript is an abstract model description which *have* to be
extended to become a programming language.

I very definitely did not say that.

John
--
John Harris

[VK]

John G Harris wrote:

VK writes

that they have created an unique "language" wich:
1) doesn't have any means to accept any input
2) doesn't have any means to output results

ECMA 262 per se is a totally enclosed system "out of time and space".
This alone would be enough to say that "ECMAScript Language" is a wrong
term. ECMAScript is an abstract model description which *have* to be
extended to become a programming language.

I very definitely did not say that.

It's OK: you hinted me, I put your hint into nice and clear wording.
This is how a real team works ;-)

P.S. Does anyone really think that ECMA-262 indeed can be implemented
as it is without internal or external (host) extensions? Without an
ability to serve instructions to the interpreter and without an ability
to see any output? (The latter actually is not so important because w/o
an ability to serve instructions there is not any output).
If no one thinks so than what's wrong with the statement: "ECMAScript
is an abstract model description which *have* to be extended to become
a programming language"?
Does anyone know *any* language without in/out mechanics? Did you look
through the history of programming languages starting from ALGOL...
actually you may start even from the Babage Machine (XIX century)? So
what can be a problem then with my definition?

[Michael Winter]

On 01/12/2005 22:14, VK wrote:

[snip]

P.S. Does anyone really think that ECMA-262 indeed can be implemented
as it is without internal or external (host) extensions?
Yes, of course. Would it be useful? No.

Have you ever read the specification that you try to deride so often? If
so, surely you'd have read:

A scripting language is a programming language that is used to
manipulate, customise, and automate the facilities of an
existing system.
-- sent. 1, par. 3, 4 - Overview

and perhaps the next two sentences?

In such systems, useful functionality is already available
through a user interface, and the scripting language is a
mechanism for exposing that functionality to program control.
In this way, the existing system is said to provide a host
environment of objects and facilities, which completes the
capabilities of the scripting language.

Notice that is states "the _capabilities_ of the scripting language".
Without an ability to serve instructions to the interpreter
What's that got to do with the /language/?
and without an ability to see any output?
Again, that is domain of the host, not the language.

[snip]
If no one thinks so than what's wrong with the statement: "ECMAScript
is an abstract model description which *have* to be extended to
become a programming language"?
Because you're failing to see the distinction between the language and
its environment. The former, in my eyes, only needs to specify the
constructs, data types, and their behaviour and grammar.
Does anyone know *any* language without in/out mechanics?

C and C++. I also consider Java not to, either. Unlike ECMAScript,
however, each of these have standard libraries which provide I/O amongst
many other things. ECMAScript expects the host to provide the equivalent.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.