41–45 of 45 posts
Earlier quoted context omitted.
JSON does not define a type system, but javascript defines null as the only value of the null type. This works fine in eg typescript since you can use a type union of null and any other type, if you want to indicate a nullable value.
but don't forget that `typeof null === 'object'` :)
NULL makes little sense from first principles. Either get rid of it, or allow nulls (and logically any other union) by supporting union types. It is quite arbitrary to allow a type that makes sense (string, int) etc. and then also allow nulls so you allow INT | NULL union but no other unions. So you have this multi-purpose "other value" whose meaning is inferred by the application. I guess they were added as a pragma…
> For example not everyone has a middle name, but you don't want to go all 5th Normal Form on it. (actual question) how does 5NF apply here? I thought that this case could be handled null-free by introducing a separate table people_middlenames (human_id PK, middlename NOT NULL); Is it already 5NF? I thought 5NF requires more complex structure of data, like explained in Wikipedia, for example. Thanks,
That being said, names is an awful example; if you have to assume a specific structure from someone's name you kinda already lost [1][2].
Better to just assume it's a opaque mutable unicode string and hope for the best.
[1] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
[2] https://shinesolutions.com/2018/01/08/falsehoods-programmers...
Earlier quoted context omitted.
Worse: with JSON NULL is considered a type not a value of other types, which can make validating nullable values with JSON-Schema a royal pain.
JSON does not define a type system, but javascript defines null as the only value of the null type. This works fine in eg typescript since you can use a type union of null and any other type, if you want to indicate a nullable value.
(the value undefined and the property-does-not-exist undefined)
NULL makes little sense from first principles. Either get rid of it, or allow nulls (and logically any other union) by supporting union types. It is quite arbitrary to allow a type that makes sense (string, int) etc. and then also allow nulls so you allow INT | NULL union but no other unions. So you have this multi-purpose "other value" whose meaning is inferred by the application. I guess they were added as a pragma…
We can all agree that the "silently accept null" approach is, by now, a quadrillion dollar mistake.
But having a safe "or null" union type as the _only_ union type in your language, isn't as far fetched as you make it sound.
It's the good old "allow zero, one or an infinite amount of any feature" rule. Sometimes "one" is the right choice.
And the same principle applies to values. A plain value is one value. A list/collection is an arbitrary number of values. And `null` is no value. Some would, rightly, say that `void` is no value, so `null` it's really a value representing no value. And then you will also want to represent zero-or-one value, which is where the -or-null type comes in.
This is a more fundamental union than just "a Foo or a Bar" which is always a value, then we're just arguing over type.
You can always use an `Option` class instead. If you have classes. But if you're going to use `Option.none` to represent the value of an uninitialized variable, you're going to build it into the language anyway, and then you might as well admit to that one union type.