I'm all for the idea that relational fields should be NOT NULL What if the data is actually missing? How else do you record that information?
You use the default empty value, and have an extra field for missingness. Than you have real type safety.
Real type safety is sum types. If I need to express something that is present or missing, I should use a Maybe monad.
Having an extra field for "missingness" is less safe because the type system won't enforce that it is either missing or set, you could have it set to a value but marked as missing which is still ambiguous.
This may be the "computing industry sentence of the year", if they had an award for "sentence of the year", which I'm sure they don't. Whoever they are. while nil is assigned to t2, when t2 is passed to factory it is “boxed” into an variable of type P; an interface. Thus, thing.P does not equal nil because while the value of P was nil, its concrete type was *T.
This is required to support one of the most peculiar features I've ever seen--method dispatch on the concrete type of object that isn't there.
The more experienced a developer I become, the more strongly (and negatively) I feel about nils and nulls and their ilk. I have sympathy for C.A.R.Hoare who in 2009 apologised for the apparent invention of null references in ALGOL W (1965), calling them a "billion-dollar mistake". I've come to regard them as a data singularity, and when I design data structures and interfaces today I am deliberately avoiding/outlawin…
NOT NULL bugs me too, but not so much because nulls are possible, more so that I think it should be inverted since that's the common case (at least for me).
Right! It should have been called NULLABLE and default to false.
IMO the language made a mistake by allowing nil to satisfy any interface . When I write a function like func DoStuf(i ILoveGoer) { i.LoveGo() // Panic on nil } its hard to reason about because it doesnt look like you have a pointer, looks like you definitely have a value. IMO a nil should not be allowed for an interface. So the only way to create an interface var is in conjunction with assignment.
this is called a bottom type in a type system. In JVM languages null and the throw expression return the bottom type. The only other option is to not have nil values.
Or to encapsulate a nil in a Maybe monad, so that you only have to deal with it in contexts where you explicity denote acceptance of nils. Then the type system won't let you get away with ignoring the possibility of a nil.
The more experienced a developer I become, the more strongly (and negatively) I feel about nils and nulls and their ilk. I have sympathy for C.A.R.Hoare who in 2009 apologised for the apparent invention of null references in ALGOL W (1965), calling them a "billion-dollar mistake". I've come to regard them as a data singularity, and when I design data structures and interfaces today I am deliberately avoiding/outlawin…
Funny, I'm the opposite. The more experienced I've become, the more I've found that nil-punning is ultimately what I actually wanted. And I'm all for the idea that relational fields should be NOT NULL. I also fear that this doesn't really work for backwards compatible thinking. If I serialized some data down to disk before a field existed, I don't expect it to be there when I check it later. You can be tempted to thi…
Agree completely. Google removed "required" fields from proto3 because they cause problems for compatibility and version skew. And even in proto2, which had "required" fields, people quickly learned to avoid them. Anything that goes on the disk or wire should have only "optional" and "repeated" fields (as a bonus, "optional" is encoded the same as "repeated" with zero or one values).
IMO the language made a mistake by allowing nil to satisfy any interface . When I write a function like func DoStuf(i ILoveGoer) { i.LoveGo() // Panic on nil } its hard to reason about because it doesnt look like you have a pointer, looks like you definitely have a value. IMO a nil should not be allowed for an interface. So the only way to create an interface var is in conjunction with assignment.
this is called a bottom type in a type system. In JVM languages null and the throw expression return the bottom type. The only other option is to not have nil values.
The problem is "null" being a value in all (non primitive) types, not only the bottom type. You specify "String", but you can have "null" too. When everything is optional, how do you specify that function foo really takes a String, not null? (https://stackoverflow.com/questions/4963300/which-notnull-ja...)
this is called a bottom type in a type system. In JVM languages null and the throw expression return the bottom type. The only other option is to not have nil values.
Or to encapsulate a nil in a Maybe monad, so that you only have to deal with it in contexts where you explicity denote acceptance of nils. Then the type system won't let you get away with ignoring the possibility of a nil.