Nullablity

Shijun He hax.sfo at gmail.com
Wed Jun 21 00:27:20 PDT 2006


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 don't 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 indicate
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
implementations such as AS3 should 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 being forced. If we introduce
nullablity, we must do the right thing.

3. I don't 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 is ref type or value type. C# 2.0 has no
choice because it must compatible with C# 1.0, but ES4 have no such
burden.

There are many issues in current proposal:

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 users write
null checking branches when use nullable type ( var a:T? ... if
(a==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 (decide if it is nullable and remeber the decision) will drive
lib developers and users crazy.


What I expect is straightforward. When I say a:T, I mean non-nullable,
when I say a:T?, I mean nullable. When I see a:T, I know it's
non-nullable, when I see a:T?, I know it's nullable. As a library
developer, I can be free from the metaphysical issues (should this or
that be nullable?). As a user, no need to guess default nullablity, no
need to search documents, no need to worry about nullablity will
change in the future. And there is no need to use ugly "T!". a:T!=x
and a:(t!=x) and a::t!=x is too confused.



More information about the Es4-discuss mailing list