Classes as Sugar (was: Renaming ECMAScript 4 for the final standard?)

Brendan Eich brendan at mozilla.org
Tue Mar 25 00:19:37 PDT 2008


On Mar 24, 2008, at 11:21 PM, Thomas Reilly wrote:

> ... and all
> that static information sure doesn't hurt when it comes to
> performance (can I say that much Brendan? ;-)

If you've got it, use it -- no point in dropping type information  
during a source to bytecode or other transformation. Just don't  
expect the web to type-annotate the way Flash authors did (with some  
grumbling) based on the carrot of speed that you guys dangled.

> Sometimes loosey
> goosey is good, in large frameworks (and certainly OSes) not so
> much.  We think that one language can serve both ends.

I'm pretty sure Mark wants to avoid loose geese too, but he has  
reached different conclusions. My goal is to work from conclusions  
backward to premises such as "ES4 is statically typed" and try to  
identify the reason for that kind of statement.

This may not succeed. As Graydon once observed, a lot depends on  
"mood" of the language. People see static type checkers (even  
optional ones, as optional as JSLint) and type annotations (also  
optional), and the 'class' keyword (which is used in dynamic  
languages too), and suddenly it's a statically typed language and  
therefore b-a-d.

The charge Matthias leveled about intentional loopholes (ES4's *  
type, which is the default annotation) meaning errors can (as is  
usual in ES3 today) originate from anywhere in a large system and  
mess over your hybrid or partially typed code is pretty much on  
target. But we are trying not to do Contract or TypeScheme research,  
and we are definitely not imposing a static type system (not even  
within new modules -- and defining a module is turning out to be  
quite hard in JS on the web). Contrary to all the claims alleging  
that we are doing those bad things.

If ES4 users want to lock a module down in a static-typing sense,  
they can annotate all API entry points with non-like types (wrap  
would allow untyped client code to pass plain old objects and arrays,  
at a price). Further self-imposed B&D programming inside the module  
is optional in my view. This is the best that I believe we can do for  
ES4. It beats purely dynamic typing for any non-trivially-small  
codebase. I wish I had the option to code in this language when  
writing Narcissus.

/be




More information about the Es4-discuss mailing list