Subj : Re: ECMAScript standards committee
To   : netscape.public.mozilla.jseng
From : zwetan
Date : Mon Oct 11 2004 04:31 pm


"Georg Maaß" wrote:
>
> If we do not get the class based mechanism additionally to the prototype
> based mechanism, then we will indeed lose against C#. With JS 2.0 we
> should get it additionally not as replacement. And we need it very soon,
> because with JScript.NET there is a concurring implementation. JS 2.0
> must become the leader for ECMA-262-4, which still does not exist as
> standard but only as expired draft.
>

having additionally prototype-based and class-based features is not done in
JScript.NET,
and that's why some alarm bell are ringing there...
I mean you can choose one way or the other but at runtime you can not use
both,
you have to make a choice, and if you make the JScript.NET class-based
choice
you sure gonna lose in front of C#.

But if you choose the prototype-based way, here you got fonctionnalities
that C# as a class-based language can not do.

- dynamically added properties
- adding properties/methods to core objects
- type coercion
- prototype delegation
etc...

for me its more a class-based vs prototype-based fight than
a C# vs JScript.NET fight.

> I'm not afraid in class based object mechanisms. I want to get both
> mechanisms in one language, because each has it's own advantages. I want
> all of them.

you have to think either class-based or prototype-based, the more you think
class-based the more the JScript.NET (or JS20) choice make no-sens.

Classes versus Prototypes in Object-Oriented Languages
http://www.cs.washington.edu/research/constraints/object-oriented/fjcc-86.html
ftp://ftp.cs.washington.edu/pub/constraints/papers/fjcc-86.pdf
Alan Borning
(Department of Computer Science and Engineering - University of Washington)

the class-based way is not the only approach to OO programming.

>
> > - We love ECMAScript, we are concerned with ECMA-262 backward
compatibility
> > after the ECMAScript standard evolve to its 4th edition
>
> I don't see such a problme, because Waldemars draft specifies 1.5
> behaviour as default, so no backward incompatibilities to existing JS
> 1.5 code should occur.

ok, but if people focus on the class-based side of the language,
the prototype-based side will not evolve ...and that's a shame.

when a language as Java evolve from one version to another version
people don't reinvent the nature of the language they just add new
functionnalities,
for Java 1.5.0 (5.0) : generics, autoboxing, enum etc...

I don't think people have to change the ECMAScript prototype-based nature
to add such functionalities...
look at E4X, they are not changing the prototype nature of ECMAScript,
they just add XML construct and mecanism support inside the language:

before:
someXML = <blah>foo bar</blah>; // not possible

after:
someXML = <blah>foo bar</blah>; // possible! and powerfull! but still easy
to use

here when I see JS20 draft its feel like someone saying
"ok JavaScript is not taken seriously because it's not class-based, then
instead on improving the prototype-based mecanism we just move to
class-based mecanism like all the "serious" language."


> >, we are aslo afraid
> > that to have class-based will please a lot seasoned developpers but will
> > also block or discourage others and will deserve ECMAScript mass
adoption.
>
> Being able to pick the bet fitting mechanism for each problem make a
> language very sexy. The richness of language features is, what makes C++
> to sexy and Java so poor. To bring JavaScript back to the top, we need
> more language features like adding class mechanisms. We need JS2.0. And
> we should get it as soon as possible.

I totally don't agree...
what make Java or C# sexy in comparison to C++ is the ease of use,
the GC mecanism etc.
and ho well ...just compare how many people use C++, Java, C#, JavaScript...
if there is 1 using C++
there is 100 using Java/C#
and there is 1000 using JavaScript

but the ease of use does not mean less power to the developper.

ECMAScript being prototype-based allow a lot of powerfull features
by default in the language, which need complex implementation in other
"serious" languages.

> > of a JScript.NET vs JavaScript 2.0 war...
>
> JScript.NET allways humbles. VisualStudio.NET does not support anything
> well than C#.
>

agree with that,
but that's MS politic ...they will support VB.NET and C# because these are
their stuff,
JScript.NET they have to support it as .NET language, not because JScript is
their stuff,
but because so much people used JScript instead of VBscript well before .NET
era
so they were forced to implement it to not piss off users.

things I m wondering:

- why not have made a DLL version of JavaScript for IE to replace the
JScript version ?
 ex here: http://www.digitalmars.com/dscript/index.html
-> solve the DOM war

- why not have made a Mozilla editor dedicated to JavaScript ?
-> not only syntax highlighting

- why there is no project to have some js2exe tools ?
like perl2exe, py2exe etc...

perharps I m too much biased with JS, but put a good JS editor and
some js2exe tools in the hands of users and all the mass of JS developpers
(who are much more numerous than any other programming crowd)
gonna produce stuff, projects, tools ,code etc.
people beg for that ...

right now the only easy way to produce an exe with JS
is to use JScript.NET (yep even in classic mode, /fast-).

zwetan

.