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

Thomas Reilly treilly at adobe.com
Tue Mar 25 07:56:38 PDT 2008


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

And I think that's good enough.  Flex has a "strict" mode where you get
a warning if you don't statically type things.  Typically I turn it off when
prototying around and turn it back on if I'm implementing anything others have
to use.   I never really stopped to think why this is.  Is it as simple as
facilitating code sharing and declarative input validation or is there more to
it?  I suspect it might be that simple.

One thing that occurs to me is that classes facilitate wrapping up code into
a compiled form and sharing it as a fixed closed entity.  Not sure that will
ever apply to browsers but its a very common idiom in Flex (and Java/C/C++...).
Here static typing is just facilitating creating code boundaries I guess.

Boundaries are definitely a good thing when trying to coordinate the efforts of 
many.  But then I see things like this:

http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/

Its kinda awe-inspiring to look at but part of me wonders if maybe there's a better way 
(and wow, the JVM must have an unbounded stack)?   Maybe with ES4 all the boxes are there
with similiarly defined boundaries but the meat inside the boxes is leaner/clever dynamic 
code.  How's that for an ES4 pitch, like Java but with leaner meat ;-)   Taste great, less 
filling.

-----Original Message-----
From: Brendan Eich [mailto:brendan at mozilla.org]
Sent: Tue 3/25/2008 12:19 AM
To: Thomas Reilly
Cc: Mark S. Miller; Dave Herman; es4-discuss at mozilla.org
Subject: Re: Classes as Sugar (was: Renaming ECMAScript 4 for the final standard?)
 
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