Timeline for If null is bad, why do modern languages implement it?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2014 at 18:55 | comment | added | Doval | @MaxthonChan It's not a feature when I neither want nonsense values nor noop behavior. If you want an extra value in your type, you should opt into it. If you want to ignore a certain value, you should opt into it. Anything else is problematic. | |
| Jun 10, 2014 at 18:49 | comment | added | Maxthon Chan | @Doval Any nonsense value can be treated as a soft error. The "silent default to do nothing" behaviour of Objective-C is a feature as it can cut your coding in half, eliminating most (if not all) null checks. | |
| Jun 10, 2014 at 18:34 | comment | added | Doval |
@MaxthonChan I'm not convinced every type can have a sensible default value. If I declare an enum for colors (i.e. Red | Green | Blue) which color is the sensible default? What is the sensible default for function types like (int * int) -> int? And why would I ever want the language to silently default to doing nothing? That's a recipe for masking bugs.
|
|
| Jun 10, 2014 at 18:08 | comment | added | Maxthon Chan |
@Doval Every class can be assigned a default value - the soft error I mentioned multiple times is one, and empty string is another. I work with Objective-C extensively and there is no non-virtual in Objective-C, and Objective-C ignores method calls to nil and returns, yet again, nil.
|
|
| May 3, 2014 at 18:48 | comment | added | supercat |
...the aforementioned Equate approach would operate upon things which had already been discovered to be equal.
|
|
| May 3, 2014 at 18:47 | comment | added | supercat |
@Doval: Incidentally, while having immutable types include default values wouldn't require special Framework "immutable type" support, designing in support for such types could offer huge benefits. For example, ImmutableObject could include an Equate method which, if given a reference to another object of the exact same type, would arrange things so that on the next GC cycle, only one object would be kept, and all references to either of the orginal objects would refer to the one that was kept. Unlike interning, which involves comparing objects to things with which they might be equal...
|
|
| May 3, 2014 at 16:34 | comment | added | supercat |
@Doval: The types whose methods can sensibly work with null should use non-virtual calls and implement sensible behavior when this is null. Those which can't, shouldn't.
|
|
| May 3, 2014 at 16:04 | comment | added | Doval | @supercat That's a good point, but now don't you need to add support for distinguishing between immutable and non-immutable types? I'm not sure how trivial that is to add to a language. | |
| May 3, 2014 at 15:58 | comment | added | supercat |
@Doval: There would be no particular inherent difficulty in having an immutable reference type regard null as a usable default value (e.g. have the default value of string behave as an empty string, the way it did under the preceding Common Object Model). All that would have been necessary would have been for languages to use call rather than callvirt when invoking non-virtual members.
|
|
| May 2, 2014 at 18:06 | comment | added | Doval |
@MaxtonChan Null can only be assigned a meaning when the values of a type carry no data (e.g. enum values). As soon as your values are anything more complicated (e.g. a struct), null can't be assigned a meaning that makes sense for that type. There is no way to use a null as a struct or a list. And, again, the problem with using null as an error signal is that we can't tell what might return null or accept null. Any variable in your program could be null unless you're extremely meticulous to check every single one for null before every single use, which no one does.
|
|
| May 2, 2014 at 18:03 | review | First posts | |||
| May 2, 2014 at 18:19 | |||||
| May 2, 2014 at 17:59 | comment | added | Maxthon Chan | @Doval If that is the situation just assign NULL a meaning (or if you have a default, treat it as a synonym of the default value) or use the NULL (which never should appear in the first place) as a marker of soft error (i.e. error but at least not crashing just yet) | |
| May 2, 2014 at 17:51 | comment | added | Doval |
The problem is that there's no way to distinguish variables which should never contain null from those that should. For example, if I want a new type that contains 5 values in Java, I could use an enum, but what I get is a type that can hold 6 values (the 5 I wanted + null). It's a flaw in the type system.
|
|
| May 2, 2014 at 17:43 | history | answered | Maxthon Chan | CC BY-SA 3.0 |