cite from http://developer.mozilla.org/es4/proposals/nullability.html
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 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.
Defaults
Almost all types are nullable by default. The only types that are non-nullable by default are:
-
Boolean -
all numeric types (see numbers)
This convention is consistent with historical precedent for boolean and numeric types. These are the only special cases; in all other cases, types are nullable by default.
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 unless declared non-nullable.
Type constructors 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 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.
扫一扫
4958
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
