Lambda the Ultimate

inactiveTopic JavaScript 2.0 Versioning
started 2/19/2002; 2:09:07 PM - last post 2/23/2002; 10:03:43 AM
Chris Rathman - JavaScript 2.0 Versioning  blueArrow
2/19/2002; 2:09:07 PM (reads: 1410, responses: 8)
JavaScript 2.0 Versioning
Found this link via a discussion about whether dynamic languages can handle versioning. The JavaScript 2.0 spec is set to introduce selector namespaces in order to alleviate name collisions and provide the capability of versioning.

Also of interest, is Waldemar Horwat's powerpoint presentation on JavaScript 2.0 made at LL1.
Posted to general by Chris Rathman on 2/19/02; 2:10:27 PM

Patrick Logan - Re: JavaScript 2.0 Versioning  blueArrow
2/19/2002; 7:35:41 PM (reads: 1439, responses: 0)
An interesting development for JavaScript. I wonder where they may take this in future releases. Dynamic selectors are good for more than package versions.

Dan Shappir - Re: JavaScript 2.0 Versioning  blueArrow
2/20/2002; 6:20:59 AM (reads: 1496, responses: 0)

Both the site and the presentation make it clear that object definitions via functions and prototypes is deprecated in favor of classes. While prototype-based type definitions certainly take a bit of getting used to, and have some intrinsic limitations, I cannot help but have reservations about this decision.

In my mind, the current object definition mechanics (inherited from Self I believe) give JavaScript its unique character and capabilities (take a peek at the Beyond code to see what I mean). Going with classes results in JavaScript loosing its distinctiveness. This is sort of similar to the issue I raised about the viability of VB in the .NET world. Why use JavaScript with classes when you can use Python/Ruby instead?

Also, in the context of a previous thread on static typing, note the inclusions of type annotations:

public function foo(bar: Integer) { ... }

This information is not used for static type-checking, nor for supporting overloading. Instead it is simply used to coerce the argument to the appropriate type.

nickmain - Re: JavaScript 2.0 Versioning  blueArrow
2/20/2002; 7:51:31 AM (reads: 1427, responses: 0)
IMHO JavaScript is a "right-sized" scripting language that promotes a healthy partioning of logic between the scripting layer and the component layer (Java, C(++), DOM etc.).

Making it a more powerful general purpose language is only likely to encourage "misuse".

Dan Shappir - Re: JavaScript 2.0 Versioning  blueArrow
2/20/2002; 9:23:19 AM (reads: 1398, responses: 0)
Adding type annotations is a "good thing". It does not detract from the language, it adds expresivness, makes it easier to write robust code, and if you don't like it you can simply ignore it.

The ability to ignore features is in itself a powerful feature of JavaScript, that is closer in philosophy to C++ than Java. In Java you have to understand classes even if all you want to do is write a simple function. With JavaScript you can write simple imperative code in the global scope, without knowing about functions. You can write functions without understanding OOP. You can define objects without higher-order functions and closures. And you can write rather high-level functional code.

BTW my feelings about type annotations is that they could have gone a lot farther. At the very least, some sort of overloading mechanism could have been supported.

Patrick Logan - Re: JavaScript 2.0 Versioning  blueArrow
2/20/2002; 10:03:38 AM (reads: 1398, responses: 1)
The language is getting bigger. How well each new feature can be ignored or incorporated by the average developer remains to be seen.

I am not sure using type hints for coersion is a good thing. Using for providing hints to a compiler may be reasonable. Using it for shorthand to perform type checking at runtime seems more appropriate than coersion. (Silence is not always golden.)

Overloading in a dynamic language is really a notational convenience. The checking still needs to be performed at runtime. It's a way of partioning the code. But it also seems to be on a slippery slope toward CommonLisp's generic functions with dynamic dispatch. Even further away from a simple scripting language.

Mutually recursive references for more fun reading.

Ehud Lamm - Re: JavaScript 2.0 Versioning  blueArrow
2/20/2002; 10:53:55 AM (reads: 1477, responses: 0)
I am not really a JavaScript programmer, but from my experience with other languages I agree with Patrick's comments regarding type annotations. If, indeed, they can change the semantics of currently running programs (silently) then they are evil.

Adam Vandenberg - Re: JavaScript 2.0 Versioning  blueArrow
2/21/2002; 4:07:39 PM (reads: 1372, responses: 0)
As a practical matter I'm wondering where JavaScript 2.0 could be deployed that would actually get it any traction with developers.

Sure a new version of Mozilla could have it, but I'm not sure how many developers would JS 2.0 if IE didn't support it.

And there's Microsoft's "new version" of JavaScript, JScript.NET, which I think is kind of a dead end compared to VB.NET and C#.

Dan Shappir - Re: JavaScript 2.0 Versioning  blueArrow
2/23/2002; 10:03:43 AM (reads: 1367, responses: 0)

JScript.NET and JavaScript 2.0 are actually very similar (class definitions, type declarations). Indeed if you look at the slideshow you will see .NET mentioned specifically as a motivation for adding classes to JavaScript. Therefore, I would not be surprised if both Mozilla and IE support JavaScript 2.0. You can even extend this to say that .NET will support JavaScript 2.0 and also the JVM (via Rhino).

Regardless, I also think that the practicality of JavaScript as a generally purpose programming language is very much in question. JavaScript must bring something unique to the table in order to justify its use. Otherwise, it will continue to be used only as a browser scripting language (generally at < 1.0 level).