PureBasic Forums - English

[urlhttps://www.lucidchart.com/techblog/2015/08/31/ ... r-science/][/url]

I don't agree with everything.

#2. This isn't a problem with Null, it's a problem with OO.

In PB we have string comparison as a "function" (operator) that exists separate from any particular string. So "null strings" aren't a problem.

#3. Null is a special case.
Often one needs to have a special case, for instance:
* To signal that a function returns an error.
* To signal that a parameter is not used.
* To signal the end of a recursive data structure.

I can't find any better way to do this. Sometimes a special value (-1) is used, but this can't always be done (if all numbers mean something).

Agreed: Null-terminated strings is a mistake. Strings should start with 4 bytes signifying the length. And in some cases, they should also be refcounted.

#4.
The phone number cache: He doesn't provide an alternative (yet), so he can barely say that nil isn't the best option.

A. In C one would pass a pointer to a variable to receive the return value, and return the status value (exists or not).
B. Or return a pointer to the person in the cache. Here null comes to the rescue: if the pointer is null, the person isn't in the cache. ElseIf pointer->phone_number is null, the person doesn't have a number.

Null in JavaScript: JavaScript isn't a good language for many reasons.

#6.
Even the most mediocre debugger should catch this mistake and give a proper error message. It's a problem with how C++ debuggers are implemented, not with Null.

#The solution

Instead, we need an entity that contains information about (1) whether it contains a value and (2) the contained value, if it exists. And it should be able to “contain” any type. This is the idea of Haskell’s Maybe, Java’s Optional, Swift’s Optional, etc.

This is precisely what null is.

Let’s revisit the earlier Store, but this time using ruby-possibly. The Store class returns Some with the value if it exists, and a None if it does not. And for phone numbers, Some is for a phone number, and None is for no phone number. Thus there are two levels of existence/non-existence: the outer Maybe indicates presence in the Store; the inner Maybe indicates the presence of the phone number for that name. We have successfully composed the Maybes, something we could not do with nil.

That's precisely what I described above in #4 B.

Options can be thought about as a collection with a max size of 1

Regarding the phone book above, it could return
* nil if the person isn't in the cache.
* empty list if the person doesn't have a phone number
* list of phone numbers else.
Not only do we not need maybe types, we immediately gain the ability to accept the common scenario of multiple phone numbers.

I really don't see that the problem with this approach is so big that someone needed to write a blog about it.

A commenter:

The worst mistake in computer science has been the use of “Foo” and “Bar” as example classes/methods instead of a more natural pattern.

Haha, I agree.

Don't agree with everything either, but thought it was timely with the new #null$.

I see.