JavaScript 2.0: A Sneak Preview [con't]
Strong Typing
Like most scripting languages, JavaScript is loosely typed. The interpreter determines which data type should be used at runtime based on its value. This looseness affords the developer a lot of leeway for variable reuse and comparisons. In the latter case, type coercion is what makes comparison of two different data types possible; JavaScript automatically makes them the same type before performing the check:
In contrast, JavaScript 2.0 will be strongly typed, meaning that type declarations
will be enforced instead of being coerced by the scripting engine. A type can
be assigned to properties, function parameters / return values, variables, or
object / array initializers. If no type is defined, the variable or property
defaults to a type of Object
, which is the root of the data type hierarchy.
The syntax for applying a given type will be a colon (:) followed by the type
expression:
To perform comparisons like those above, you will need to cast the data type:
Program Units
Compile Time Type Checking
You will have the ability to compile JavaScript 2.0 components in strict mode. This will test the integrity of several key aspects before execution, including:
- Static type checking
- Verification that referenced names are known
- Checks for illegal assignments to constants
- Insure that comparisons are only made between valid types
Constants
Previously JavaScript developers have had to either rely on naming conventions or elaborate workarounds to protect their constants, but come JavaScript 2.0, that'll be a thing of the past:
Real Namespaces
With the emergence of JS Frameworks, the use of namespaces has really become
a necessity. The standard up until now has been to create a global object to
house all of your functionality so that pre-existing global objects and functions don't get
clobbered.
Conclusion
Some of the detractors to the 2.0 proposal take issue with the movement towards classical programming languages like C++ and Java. Tom Steinert-Threlkeld voiced his concerns in a recent blog
"...the dynamic and flexible nature of JavaScript's prototypal inheritance and object model...is a practical, fundamental advantage. Why someone would want to take something so elegant and flexible and turn it into Java - which essentially forces a programmer to use classical, class-based inheritance - is beyond me."
I personally have mixed feelings about the new proposal. While I welcome changes such as classes, namespaces, and constants, I don't like the idea of strongly typed scripting variables. Overall, the language is at risk of becoming too rigid, and by extension, serious, for the average amateur programmer. Then again, maybe I should be thankful that more owners of commercial websites will require the services of a professional like me to code their business processes! Whatever the outcome, there can be little doubt that the web development landscape is about to be drastically altered!
Original: July 20, 2009