Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Upcoming Changes to the JavaScript Language

1 view
Skip to first unread message

www.gerardvignes.com

unread,
Dec 2, 2007, 3:43:24 PM12/2/07
to
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.

Evertjan.

unread,
Dec 3, 2007, 6:14:12 AM12/3/07
to
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:
=====
alert( '1' +\ '2' ); // 3
alert( 1 &\ 2 ); // 12
alert( '1' +\ 2 ); // 3
alert( 1 &\ '2' ); // 12
=====

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

=3=
Switchable BCD [Binary Coded Decimal] floating point arythmetic
as an alternative to the present binary one.

=4=
An 'option explicit' like the suggested 'use strict',
as a debug time help.

=5=
Strict definitions of now buggy or illogical implementations like:
toFixed(), getYear(), round(), etc.

=6=
Octal parsing of numeric litterals shoud be abolished.

=7=
Multitasking as a standard

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Tim Streater

unread,
Dec 3, 2007, 6:27:36 AM12/3/07
to
In article <Xns99FB7C7A...@194.109.133.242>,
"Evertjan." <exjxw.ha...@interxnl.net> 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.
>
> =========================================
>
> The few addendums to JS I would like are:

[snip]

> =7=
> Multitasking as a standard

Multithreading? I would like to have separate threads and be able to
have one thread post events to wake up other threads (I'm being a but
vague here as I can't remember what I decided was missing from js in
this regard).

Randy Webb

unread,
Dec 3, 2007, 6:37:41 AM12/3/07
to
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/

Tim Streater

unread,
Dec 3, 2007, 6:41:55 AM12/3/07
to
In article <Xns99FB7C7A...@194.109.133.242>,
"Evertjan." <exjxw.ha...@interxnl.net> 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.
>
> =========================================
>
> 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.

Evertjan.

unread,
Dec 3, 2007, 6:49:07 AM12/3/07
to
Tim Streater wrote on 03 dec 2007 in comp.lang.javascript:

> [snip]
>
>> =7=
>> Multitasking as a standard
>
> Multithreading?

Damn, that's the word.

[Perhaps now I am multithreading on some toes?]

Randy Webb

unread,
Dec 3, 2007, 7:00:45 AM12/3/07
to
Tim Streater said the following on 12/3/2007 6:41 AM:

> In article <Xns99FB7C7A...@194.109.133.242>,
> "Evertjan." <exjxw.ha...@interxnl.net> wrote:

<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.

Evertjan.

unread,
Dec 3, 2007, 7:00:27 AM12/3/07
to
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.

John G Harris

unread,
Dec 3, 2007, 3:07:33 PM12/3/07
to
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

John G Harris

unread,
Dec 3, 2007, 3:25:55 PM12/3/07
to
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

Randy Webb

unread,
Dec 3, 2007, 4:07:48 PM12/3/07
to
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.

Evertjan.

unread,
Dec 3, 2007, 5:05:32 PM12/3/07
to
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.

Spam Catcher

unread,
Dec 3, 2007, 6:06:32 PM12/3/07
to
"Evertjan." <exjxw.ha...@interxnl.net> wrote in
news:Xns99FB7C7A...@194.109.133.242:

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

Everyone makes typos - it's nice for the compiler to validate some of
these errors.



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

True.

> 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
> =====

If JS were a typed language this would be less of an issue right? :-)



> =7=
> Multitasking as a standard

Yes, and also object oriented functionality like classes.

--
spamho...@rogers.com (Do not e-mail)

Spam Catcher

unread,
Dec 3, 2007, 6:10:52 PM12/3/07
to
"Evertjan." <exjxw.ha...@interxnl.net> wrote in
news:Xns99FBEAE8...@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?

Dr J R Stockton

unread,
Dec 3, 2007, 6:39:13 PM12/3/07
to
In comp.lang.javascript message <Xns99FB7C7A...@194.109.133.242>
, Mon, 3 Dec 2007 11:14:12, Evertjan. <exjxw.ha...@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.

www.gerardvignes.com

unread,
Dec 4, 2007, 1:28:03 AM12/4/07
to
Don't forget that a strongly-typed language can still be a dynamic
language, e.g., Python and Ruby. PHP is kind of moving in this
direction with Type Hinting, but it works only for Objects and Arrays.

I think the most ambitious possible changes to JavaScript (cum
ECMAScript) would be:

1. From OO Prototype-Based to OO Class-Based (proposed)

2. An efficient (native code) standard library (my informal proposal)

One thing I am curious about is the fate of JavaScripts functional
language characteristics. Perhaps I am being a prude, but it doesn't
seem that OO and Functional can really work in a single programming
language.

Evertjan.

unread,
Dec 4, 2007, 4:48:39 AM12/4/07
to
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.

Dr J R Stockton

unread,
Dec 4, 2007, 11:52:03 AM12/4/07
to
In comp.lang.javascript message <CL1viBIF...@J.A830F0FF37FB96852AD0
8924D9443D28E23ED5CD>, Mon, 3 Dec 2007 20:07:33, John G Harris
<jo...@nospam.demon.co.uk> posted:

>
>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.zip> Timo Salmi's Turbo Pascal FAQ.

Thomas 'PointedEars' Lahn

unread,
Dec 4, 2007, 3:26:11 PM12/4/07
to
Tim Streater wrote:

> "Evertjan." <exjxw.ha...@interxnl.net> wrote:
>> 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?

It's already used for property accessor syntax.

> Since I do a lot of stuff in both js and PHP, I would prefer the convergence.

I would not. That would require ECMAScript to use PHP's `->' or always the
bracket syntax for property access. The former would introduce all kinds of
problems with other operators and the latter would be inconvenient.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Dr J R Stockton

unread,
Dec 4, 2007, 3:26:40 PM12/4/07
to
In comp.lang.javascript message <Xns99FC6DF9...@194.109.133.242>
, Tue, 4 Dec 2007 09:48:39, Evertjan. <exjxw.ha...@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#ECD> subsection "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)

Evertjan.

unread,
Dec 5, 2007, 9:44:15 AM12/5/07
to
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?

Dr J R Stockton

unread,
Dec 5, 2007, 4:04:16 PM12/5/07
to
In comp.lang.javascript message <Xns99FDA01...@194.109.133.242>,
Wed, 5 Dec 2007 14:44:15, Evertjan. <exjxw.ha...@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.

Evertjan.

unread,
Dec 5, 2007, 7:11:06 PM12/5/07
to
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

Richard Cornford

unread,
Dec 6, 2007, 3:02:40 PM12/6/07
to
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.

Richard Cornford

unread,
Dec 6, 2007, 3:02:45 PM12/6/07
to
www.gerardvignes.com wrote:
<snip>

> 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.

You are not really talking about a standard library here, but rather a
set of 'utility' functions/objects built into the language and so
available on all ES4 implantations. That may not as useful or practical
as you may anticipate.

In terms of usefulness you have to bear in mind that javascript is a
language for scripting object models, where the specifics of the object
model are not important to the language. So such a library should not
include things that are heavily tied to particular object models. So,
for example, a function that would use a CSS class name arguments to
retrieve a collection of element nodes from an HTML DOM document tree
structure would be out of place because there should be no expectation
that the object model being scripted would be (or would include) an HTML
DOM document. Thus these extra facilities should be object model neutral
and instead be purely language related (which still leaves a good
collection of possible candidates).

The question of practicality comes with the increase in size in the JS
engine that must follow from natively providing more facilities.
Scriptable web browsers are not restricted to desktop PCs. They do
appear on much smaller devices with much more restricted resources. (It
is not unlikely that with small MP3 players growing hi-resolution
screens and an ability to play video an obvious next step might be the
make a web browser available on them.) Presumably the intention would be
that these embedded browsers would also provide ES4 implementations,
which may result in the viability of that idea being at least partly
dependent on the size of the ES4 engine. The current reference
implementation of ES4 is already bigger than the whole executable for
Opera 9.

Richard.

www.gerardvignes.com

unread,
Dec 8, 2007, 7:10:01 AM12/8/07
to
On Dec 6, 12:02 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
...

IF ECMAScript ___could___ be compiled, it would be simple to build
libraries. Standard libraries could be organized into distributions
which are targeted (by need and size) to the intended platforms and
included with the browsers on those platforms.

There are advantages to having an ECMAScript compiler:
* harder to swipe code compiled from scripts
* harder to hack web applications
* easier to build faster code (like bigint and encryption libraries)

If the ECMAScript engine could run both script and compiled code...
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]...
This sounds a lot like Java, except that Java didn't work on the
browser.

Why didn't Java work out on the browser?

Why did Macromedia/Adobe Flash succeeded on the browser where so many
others have failed?

Will .NET succeed on the IE browser where Java did not?

Thomas 'PointedEars' Lahn

unread,
Dec 8, 2007, 8:35:46 AM12/8/07
to
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

0 new messages