> 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:[EMAIL PROTECTED] Sent: Tue 3/25/2008 12:19 AM To: Thomas Reilly Cc: Mark S. Miller; Dave Herman; [email protected] 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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
