Subj : Re: ECMAScript standards committee
To   : netscape.public.mozilla.jseng
From : =?ISO-8859-1?Q?Georg_Maa=DF?=
Date : Sun Oct 10 2004 08:16 pm

Brendan Eich wrote:
> C++ shows how complexity in language design can't be hidden, 
> effectively, from most users.

It must not be hidden. It must be obvious.

>  It's not enough to say "don't use these 
> new features".

I don't say "don't use the new features". I say, use them. Get an idea, 
how they work, which advantages and disadvantages they bring to you. 
Then in the next project, when you got a feeling for the old and the new 
features decide for each problem, which feature best fits your needs.

> People use everything, in general, and the more complex 
> the tools, the worse they'll mess up.

If they are confused by complex tools, then they like to get confused. 
Give them their satisfaction by confusion! I don't waste my time with 
fighting against IDEs. I solve the problems by using simple text editors 
to write the solutions in my favourit languages.

> Why are you worried about C#?  I'd worry more about Python, although 
> "worry" is too strong.

I don't know Python.

>> Why should JavaScript 2.0 less stable than JavaScript 1.5?

> Because any new implementation will have more bugs than an old one?

This is not a problem of the language but of the implementation. If 
implementation starts early enough, then there will be no gap between 
1.5 and 2.0 but both will coexist for some years.

> What incompatibilities do you mean?  The relevant standard is ECMA-262 
> Edition 3, and we've fixed a bunch of conformance bugs (minor bugs, but 
> real) over the last four years.

ECMA-262 does not specify each implementation detail. In some details 
especially in implementing functions and variables declared inside the 
function body there was an evolution inside JavaScript 1.5. The original 
implementation was ECMA-262 conform and the actual implementation still 
is, but they are different.

In early days everything inside the function body was completely 
encapsulated and not accessable from outside. This gave us the 
possibility to protect library internaly by encapsulation against silly 
users. The user (and we too) could feed the function object with new 
properties and methods without getting in conflict with the function 
body. But then some time the implementation changed to implementing the 
internal variables as from outside accessable properties of the function 
object, which causes conflicts with variables and properties.

The silly user probably never will detect such details. But don't focus 
on the trivial scripters.


-- 
Georg Maaß   -   bioshop.de    D-76227 Karlsruhe, Westmarkstraße 82
HTML, XML / JavaScript, C++, Java, PHP, VB / CGI, JSP, ASP, ASP.net
   - The ultimate DHTML engine: http://gml-modul.sourceforge.net -
                       http://sourceforge.net/projects/gml-modul

.