Non-null objects, the Null Object pattern, and T.init

Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com> Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Fri Jan 17 17:40:43 PST 2014


On Saturday, 18 January 2014 at 01:05:50 UTC, Walter Bright wrote:
> Because I've tracked down the cause of many, many null 
> pointers, and I've tracked down the cause of many, many other 
> kinds of invalid values in a variable. Null pointers tend to 
> get detected much sooner, hence closer to where they were set.

Some null pointers. The ones that were set in the current 
call-chain, but not the long-lived ones.

Anyway, pointers are special since they link together subsystems. 
Yes, it is better to have a null-value than a pointer to a random 
location, so "null" isn't the worst value for a pointer. It is 
the best arbitrary wrong value, but there is nothing wrong with 
saying "Hey, when we are wrong about User identity, we want to 
keep the system running assuming a Guest identity".

However C-like null values conflate a wide array of semantics, I 
think you can have near half a dozen types of null values in a 
database. In c-like languages null can mean: not-yet-initialized 
(used too early), failed-computation (bottom), 
entity-shall-not-have-subentity (deliberate lack of), 
empty-container (list is empty), service-not-ready (try again), 
etc.

So yeah, it would be nice if the language is able to distinguish 
between the different semantics of "null" of different pointer 
types and convert them into something sensible when "cast" to a 
different type.

For some pointer types it might make sense to kill the thread, 
for others it would make sense to throw an exception, for others 
it might make sense to allocate an empty object, for others it 
might make sense to use a dummy/sentinel.

It isn't universally true that the best option is to core dump, 
but you could do both. You could fork(), core-dump the fork, and 
recover the original.


More information about the Digitalmars-d mailing list