Cite from http://developer.mozilla.org/es4/proposals/nullability.html
DEFAULTS
Almost All Types Are Nullable By Default. The only Types That Are Non-Nullable By Default Are:
Boolean
All Numeric Types (See
Numbers)
.........................................
Classes Can Be Defined to Be Non-Nullable By Default Via A Special Declaration Syntax:
Class C! {...}
This Annotation Does Not Imply Anything About Subclasses of C; They Are STILL NULLABLE BY DEFAULT UNSS DECLARED NON NULLABLE.
Type Constructionors for Nullability
For Any Type Expression T, The Expression? T Means The Nullable Version of T, And T! Means the Non-Nullable Version of T.
Redundant Annotations
For any Non-Nullable Type T, T! Is allowed and is identical in meaning to t.
For Any Nullable Type T,? T is allowed and is identical in meaning to t.
My Response:
! All class should be non-nullable If somebody want any option type, it should be declared explicitly (var a:? MyClass). Making things nullable by default and making T non-nullable by "T!" Is a big mistake!
Why we introduce nullablity? I believe it is because nullablity makes type finer and safer. We all know that many JSers do not like static type though they may use java / c # on server-side. So it's clear that if somebody want to use static type in ES4, that means he / she might like to have more strict and precise type system. for them, it is more common for it not to make sense for a type to include the null value. After I learn nullablity by Nice < http://nice.sourceforge.net>, I found it's rare to write a nullable type. I use nullable most in the case of method declarations, which a parameter with null value for special meaning. Then I'd like to write function f (v: t?) To indeicate such special usages.some Reasons Are Given to make Nullable Default, but:
1. ES4 Is Still In Process, Isn't it? So compatibility with existing importations such as as one shop not be the reason !! NEVER!
2. It is said it seems to be "the way of the world". NO! It's totally mess of cause and effect. "The way of the world" is not nullable by default, but no nullablity mechanism in mainstream OO languages such as Java / C # / C (Until C # 2.0 Introduce Nullablity with Generic Type). SO it's not users expected, but inituced. IF We Introduce NULLABLITY, WE MUST DO The Right Thing.
3. I do not think it's too draconian, if I want static type, which means I want a strict type system. Code should be as clear as possible to indicate whether it is nullable or not! The bad example is C # 2.0 which seperate Type Into Reference Type And Value Type, The Users Have To Recall WHETHER A TYPE. C # 2.0 Has No Choice Because It Must Compatible with C # 1.0, But Es4 Have No Such Burden.
There area: 1. It makes nullablity useless. Most developers do not know the benefits and usage of nullability, so They will ignore it at all. At Least in The Early Days ...
2. IF All Non-Nullable, Compiler or Verifier Can Force Uses Write Null CHECKING BRANCHES WHEN USE NULLABLE TYPE (VAR A: T? ... = == NULL) {...} else {...}) to eliminate NullPointerException. It's reasonable because the users write "T?" and know it's nullable. But it's hard to force the developers write such codes if nullable by default, especially because of issue 1, there will be more nullable classes than should, All will say why i must write such boring code. Things becoming worse, should i write null checking for Complex? it depends on the author of Complex! It is said "there are very few special cases to remember", but what about libraries?
3. It's inconsistent, not only Number and Boolean, but also user-defined class such as Complex. To make Complex seems like a value type, it is suggested to use class Complex! {...}. But that means authors will get burden to make the decision whether the class should be nullable. I can imagine most libraries will full of nullable class though non-nullable is more proper. Ok, they will change class Complex to class Complex! in next release, as a result, all client codes must be rewritten (change a: Complex to a:? Complex or review all codes to ensure a: Complex is ok) Of couse we all agree Complex should be non-nullable, but what about Date Should Date be nullable or.? NON-NULLABLE C # Treat DateTime As Value Type and Non-Nullable. Such Things (Decision) Will Drive Lib Developers and users Crazy.
