469,645 Members | 1,527 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,645 developers. It's quick & easy.

Upcoming Changes to the JavaScript Language

Upcoming Changes to the JavaScript Language (presented by Google)

http://youtube.com/watch?v=-yDS1eGfuWQ

I really enjoyed this presentation.

If they can get the same improvement in ECMAScript as has already been
achieved between PHP versions 4 and 5, then they have my blessings.

Specifically, the availability of a Standard ECMAScript Library
implemented in fast native code would be a TREMENDOUS IMPROVEMENT.
Check out the Standard PHP Library (SPL) for an example.

Dec 2 '07 #1
18 1826
Evertjan. said the following on 12/3/2007 6:14 AM:

<snip>
=1=
Seperate operators for adding and concatenating.
[new operators: +\ and &\, anyone a better idea? ]
example:
=====
alert( '1' +\ '2' ); // 3
alert( 1 &\ 2 ); // 12
alert( '1' +\ 2 ); // 3
alert( 1 &\ '2' ); // 12
How would that make the type converting rules any different than they
are now? Either way, if you have mixed variable types you are going to
have to have type conversion so changing the operator won't change that.
=====

=2=
Improved scoping of variables
example:
=====
var a = 1;
{
var a = 2;
alert(a); // 2
};
alert(a); // 1
=====
That isn't a big issue though. It would break a ton of apps already on
the web as well. If you want to go outside the current scope and alter a
variable, simply drop the var and go on.

<snip>
=6=
Octal parsing of numeric litterals shoud be abolished.
Why?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 3 '07 #2
In article <Xn********************@194.109.133.242>,
"Evertjan." <ex**************@interxnl.netwrote:
www.gerardvignes.com wrote on 02 dec 2007 in comp.lang.javascript:
Upcoming Changes to the JavaScript Language (presented by Google)

http://youtube.com/watch?v=-yDS1eGfuWQ

I really enjoyed this presentation.

Interesting.

However I do not agree to making Javascript a strong typed language.

It is just in the mind of precompiling language programmers,
that that would be beneficial to intepreted or runtimecompiling languages
too. Let them first explain why.

The argument that it will reduce errors is only true for js inexperienced
programmers of the strongtyped precompiling language programmer type.

The true argument that it could reduce memory need
is not that important in this day and age, imho.

=========================================

The few addendums to JS I would like are:

=1=
Seperate operators for adding and concatenating.
[new operators: +\ and &\, anyone a better idea? ]
example:
What's wrong with . just like in PHP? Since I do a lot of stuff in both
js and PHP, I would prefer the convergence.
Dec 3 '07 #3
Tim Streater said the following on 12/3/2007 6:41 AM:
In article <Xn********************@194.109.133.242>,
"Evertjan." <ex**************@interxnl.netwrote:
<snip>
>=1=
Seperate operators for adding and concatenating.
[new operators: +\ and &\, anyone a better idea? ]
example:

What's wrong with . just like in PHP? Since I do a lot of stuff in both
js and PHP, I would prefer the convergence.
I have always thought it would have been a good idea to have had a
leading character for programmer defined variables the same way PHP
does. It would allow for new keywords in the language without having to
worry about breaking existing apps. I can not say for sure that is why
PHP did it, but it is compelling argument for why they did it.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 3 '07 #4
Randy Webb wrote on 03 dec 2007 in comp.lang.javascript:
Evertjan. said the following on 12/3/2007 6:14 AM:

<snip>
>=1=
Seperate operators for adding and concatenating.
[new operators: +\ and &\, anyone a better idea? ]
example:
=====
alert( '1' +\ '2' ); // 3
alert( 1 &\ 2 ); // 12
alert( '1' +\ 2 ); // 3
alert( 1 &\ '2' ); // 12

How would that make the type converting rules any different than they
are now? Either way, if you have mixed variable types you are going to
have to have type conversion so changing the operator won't change
that.
I just hate the ambiguity.

Type conversion should influence the type, not the operator.

>=====

=2=
Improved scoping of variables
example:
=====
var a = 1;
{
var a = 2;
alert(a); // 2
};
alert(a); // 1
=====

That isn't a big issue though. It would break a ton of apps already on
the web as well. If you want to go outside the current scope and alter
a variable, simply drop the var and go on.
This is as suggested in the video though, and I like it.

<snip>
>=6=
Octal parsing of numeric litterals shoud be abolished.

Why?
var a = 0123;
alert( a ); // 83

Do you think there are many programmers that intuitively expect
the value of a to be decimal 83 ???

Such mistakes probably are more common than planned octal parsing.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 3 '07 #5
On Mon, 3 Dec 2007 at 07:00:45, in comp.lang.javascript, Randy Webb
wrote:

<snip>
>I have always thought it would have been a good idea to have had a
leading character for programmer defined variables the same way PHP
does. It would allow for new keywords in the language without having to
worry about breaking existing apps. I can not say for sure that is why
PHP did it, but it is compelling argument for why they did it.
One reason for not doing it is the number of people who would have
screamed loudly :-)

A better idea is for new keywords to start with a special character,
such as $, specially reserved for this. Oh dear, someone's already
screamed about that.

John
--
John Harris
Dec 3 '07 #6
On Mon, 3 Dec 2007 at 11:14:12, in comp.lang.javascript, Evertjan.
wrote:
>www.gerardvignes.com wrote on 02 dec 2007 in comp.lang.javascript:
>Upcoming Changes to the JavaScript Language (presented by Google)

http://youtube.com/watch?v=-yDS1eGfuWQ

I really enjoyed this presentation.

Interesting.

However I do not agree to making Javascript a strong typed language.

It is just in the mind of precompiling language programmers,
that that would be beneficial to intepreted or runtimecompiling languages
too. Let them first explain why.

The argument that it will reduce errors is only true for js inexperienced
programmers of the strongtyped precompiling language programmer type.

The true argument that it could reduce memory need
is not that important in this day and age, imho.
<snip>

It always seems to me that they wanted a language that would run fast in
a .NET virtual machine. This means having objects with fixed data fields
and methods, and every value with a fixed type. In other words they
wanted a language that ought to be called C#Script. Merging this
language with javascript is just a way of getting people to use it.

John
--
John Harris
Dec 3 '07 #7
John G Harris said the following on 12/3/2007 3:07 PM:
On Mon, 3 Dec 2007 at 07:00:45, in comp.lang.javascript, Randy Webb
wrote:

<snip>
>I have always thought it would have been a good idea to have had a
leading character for programmer defined variables the same way PHP
does. It would allow for new keywords in the language without having to
worry about breaking existing apps. I can not say for sure that is why
PHP did it, but it is compelling argument for why they did it.

One reason for not doing it is the number of people who would have
screamed loudly :-)
That is true. And the loudest screams would be along the lines of "I had
to rename all my variables/functions in ### lines of code".
A better idea is for new keywords to start with a special character,
such as $, specially reserved for this. Oh dear, someone's already
screamed about that.
Either way, if they changed it, you would have to edit nearly every line
of code that has ever been written in JS. When I wrote about keywords
though, I wasn't referring to machine generated code, I was referring to
words like "new", "getElementById", etc.. so that code would actually
look almost identical to PHP code with regards to variables.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 3 '07 #8
John G Harris wrote on 03 dec 2007 in comp.lang.javascript:
It always seems to me that they wanted a language that would run fast in
a .NET virtual machine. This means having objects with fixed data fields
and methods, and every value with a fixed type. In other words they
wanted a language that ought to be called C#Script. Merging this
language with javascript is just a way of getting people to use it.
Should we see this as a positive or a negative development?

Why would 'they' not start C#Script or C+script or C++script on it's own,
rather than kill the nice peculiarities of soft typed JS to get to the same
end?

Methinks that improving a language is just for improving,
not for unrelated ends.

It is ASP-to-ASP.NET all over again.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 3 '07 #9
"Evertjan." <ex**************@interxnl.netwrote in
news:Xn********************@194.109.133.242:
Why would 'they' not start C#Script or C+script or C++script on it's
own, rather than kill the nice peculiarities of soft typed JS to get
to the same end?
Because one of the two langauges would die off - too much resources to
maintain two branches?
Methinks that improving a language is just for improving,
not for unrelated ends.

It is ASP-to-ASP.NET all over again.
ASP.NET is a vast improvement over ASP! Yes, it was a painful move, but
years later, I haven't heard that much of a complaint.

Perhaps those that still do complain were not into the OO paradigm :-)

I'm sure "classic" Javascript will still be around ... maybe not futher
enhanced?

--
sp**********@rogers.com (Do not e-mail)
Dec 3 '07 #10
In comp.lang.javascript message <Xn********************@194.109.133.242>
, Mon, 3 Dec 2007 11:14:12, Evertjan. <ex**************@interxnl.net>
posted:
>
The few addendums to JS I would like are:
Add : an integer division operator, probably \ .
Add : Any missing assignment-with-operation, e.g. \=
Remove : Date.getYear [1]
Add : an improved way of getting multiple values returned from a
subroutine - such as procedures with parameters that they vary, or [a,
b, c] = Func(x, y, z) // with return [A, B, C] or ...?
Add : better date support as previously stated

Add : a routine which, given a date/time parameter, returns Y M D h m s
to/from that date/time; I've seen so much over-long and even bugged code
for that ... .

[1] Publish a function and/or method to emulate all existing forms of
getYear, using getFullYear.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Dec 3 '07 #11
Dr J R Stockton wrote on 04 dec 2007 in comp.lang.javascript:
Add : a routine which, given a date/time parameter, returns Y M D h m
s to/from that date/time; I've seen so much over-long and even bugged
code for that ... .
Add: array support and UTC versions of all that:

var d = Date.setFullDate(Y,M,D,h,m,s,ms)
var d = Date.setFullDate([Y,M,D,h,m,s,ms]) // array as parameter
var arr = myDate.getFullDate() // returns [Y,M,D,h,m,s,ms]

var dUTC = Date.setFullDateUTC(Y,M,D,h,m,s,ms)
var dUTC = Date.setFullDateUTC([Y,M,D,h,m,s,ms]) // array as parameter
var arrUTC = myDate.getFullDateUTC() // returns [Y,M,D,h,m,s,ms]

[Y,M,D,h,m,s,ms] and Y,M,D,h,m,s,ms:
null values are unchanged, absent values are concidered to be null, so:

var myarr = [null,null,40]
var mydUTC = new Date().setFullDateUTC(myarr)

will set mydUTC to 39 days after the first of present month,
at the present time in UTC.

var myarr = [null,null,40,0,0,0,0]
var myD = new Date().setFullDate(myarr)

will set myD to 39 days after the first of present month,
at 00:00:00:000 in local time.

var myD = new Date().setFullDate([])
and
var myD = new Date().setFullDate(null)
and
var myD = new Date().setFullDateUTC([])
being the same as
var myD = new Date()

var myMonthUTC = myDate.getFullDateUTC()[1]
being the same as
var myMonthUTC = myDate.getUTCMonth()
=========

The idiocy of having the month start at 0 and the day at 1 we will have
to live with, I suppose.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 4 '07 #12
In comp.lang.javascript message <CL**************@J.A830F0FF37FB96852AD0
8924D9443D28E23ED5CD>, Mon, 3 Dec 2007 20:07:33, John G Harris
<jo**@nospam.demon.co.ukposted:
>
A better idea is for new keywords to start with a special character,
such as $, specially reserved for this. Oh dear, someone's already
screamed about that.
In the Elliott 903/905 series (rather simple machines), all library
routines started with Q but not QU - that made clash-avoidance easy. So
the sine routine would be called QSIN in the general library. In
languages such as Algol, the compiler would understand SIN, of course.
It seemed a good idea.

Obviously ECMA3 lacks the more luxurious form of variables-to-string
(including rounding and date) conversion.

Strictly, this is not ECMA : but ISTM that the DOM should be encouraged
to have an Object with properties named after the English names of items
which commonly appear on screens in association with script, with values
which are corresponding strings in the local language.

var Wossat = {OK : "Sehr Gut", Cancel : "Ausrotten", ...}
// OTOH, "The Black Cloud", Chap. 10, para 4.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.
Dec 4 '07 #13
In comp.lang.javascript message <Xn********************@194.109.133.242>
, Tue, 4 Dec 2007 09:48:39, Evertjan. <ex**************@interxnl.net>
posted:
>Dr J R Stockton wrote on 04 dec 2007 in comp.lang.javascript:
>Add : a routine which, given a date/time parameter, returns Y M D h m
s to/from that date/time; I've seen so much over-long and even bugged
code for that ... .

Add: array support and UTC versions of all that:

var d = Date.setFullDate(Y,M,D,h,m,s,ms)
I don't disagree with your suggestions - which could be extended to
accommodate ISO 8601 Y W D as well as Y M D - but they don't follow from
my intended meaning.

The suggested routine would support countdown to an event :

Countdown(D) { return (D-new Date()).toYMDhmsmsArray() }

Though on further thought there should be a control argument selecting
by default a count in D h m s ms otherwise some form of Y M D h m s ms.

And, since it should often be called by setTimeout, perhaps Now should
be an argument so that new Date() only needs to be called once.

For examples, see my own <URL:http://www.merlyn.demon.co.uk/js-
date2.htm#ECDsubsection "Good Countdowns", and contrast with a typical
NASA countdown page.

If any of you are otherwise unoccupied between the end of 2007 local
time and the end of 2007 UTC, then look at the Cassini page countdown at
<http://saturn.jpl.nasa.gov/home/index.cfm(assuming that, between now
and then, they change the arguments of setcountdown(2007,12,05,00,06,50)
but don't alter the algorithm). Alas, here that interval will be in
truth at most 0.9 seconds and in Javascript 0 seconds.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)
Dec 4 '07 #14
Dr J R Stockton wrote on 04 dec 2007 in comp.lang.javascript:
If any of you are otherwise unoccupied between the end of 2007 local
time and the end of 2007 UTC ...
That would be a negative timespan in the new world.

Would that keep them occupied forever?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 5 '07 #15
In comp.lang.javascript message <Xn*******************@194.109.133.242>,
Wed, 5 Dec 2007 14:44:15, Evertjan. <ex**************@interxnl.net>
posted:
>Dr J R Stockton wrote on 04 dec 2007 in comp.lang.javascript:
>If any of you are otherwise unoccupied between the end of 2007 local
time and the end of 2007 UTC ...

That would be a negative timespan in the new world.

Would that keep them occupied forever?
<G>. But I don't think "between" is necessarily directional; I
carefully did not write "from" ... "to".

D = new Date()
if ( D.getFullYear() != D.getUTCFullYear() ) { /* peculiar */ }

However, there will be a difference in the exact nature of "peculiar"
dependent on the sign of D.getTimezoneOffset() . The display may well
jump by -365 days at the end of the local year and +365 at the end of
the UTC year; but I've not tested the ghastly code in full.

I see no provision for auto-stepping to next-event at the instant of
this-event; so presumably they can handle negative values.

With coders like that, I can see why they prefer STS to be on the ground
at year rollover.
=

Another language change to consider - words to be available as
alternatives to punctuation marks in B ? C : D in cases where that
would be more readable.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Dec 5 '07 #16
Dr J R Stockton wrote on 05 dec 2007 in comp.lang.javascript:
Another language change to consider - words to be available as
alternatives to punctuation marks in B ? C : D in cases where that
would be more readable.
var A = B .then. C .else. D;

==================

More general to add:
that new [binary, trinary and unary] operators can be be prototyped.

I would like to make oprators like:

var A = B .exp. C

var myBoolean = B .between. C .and. D // exclusive boundaries
var myBoolean = !(B .between. C .and. D) // outside inclusive bound.
var myBoolean = B .outside. C .and. D // outside exclusive bound.
var myBoolean = !(B .outside. C .and. D) // inside inclusive bound.

var n = B .between. [1,5,12,44,1000]
// returning 0 or 1 or .. 5 including lower bound

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dec 6 '07 #17
John G Harris wrote:
On Mon, 3 Dec 2007 at 07:00:45, Randy Webb wrote:

<snip>
>I have always thought it would have been a good idea to have
had a leading character for programmer defined variables the
same way PHP does. It would allow for new keywords in the
language without having to worry about breaking existing
apps. I can not say for sure that is why PHP did it, but
it is compelling argument for why they did it.

One reason for not doing it is the number of people who would
have screamed loudly :-)

A better idea is for new keywords to start with a special
character, such as $, specially reserved for this. Oh
dear, someone's already screamed about that.
Not the $ symbol (as that already had meaning in identifiers (and is
being used)), but # and @ are still available and could be used to
guarantee that all new keywords could never coincide with existing
identifiers.

Then you could officially deprecate all identifiers that corresponded
with the symbol-less equivalents of new keywords, and drop the symbols
in ES 8 or 9 (maybe mid 2020s).

Richard.

Dec 6 '07 #18
www.gerardvignes.com wrote:
IF ECMAScript ___could___ be compiled, it would be simple to build
libraries.
JavaScript source code can be compiled into files of JavaScript byte-code
that can be executed by a Netscape-Enterprise-Server-compatible server.
[...]
If the ECMAScript engine could run both script and compiled code...
There is no such thing as "the ECMAScript engine". There are
implementations of the ECMAScript Language Specification.
or if it could JIT script to compiled code, and have the compiled code
be an intermediate language that can only be run by the ECMAScript
engine [following its strict rules of engagement]...
That is what actually happens in HTML user agents now.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Dec 8 '07 #19

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

15 posts views Thread by Vorpal Chortler | last post: by
1 post views Thread by Izzet Pembeci | last post: by
3 posts views Thread by Waffeloo | last post: by
3 posts views Thread by bbdobuddy | last post: by
4 posts views Thread by Filip De Backer | last post: by
24 posts views Thread by =?Utf-8?B?cGF0cmlja2RyZA==?= | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.