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 18:42:17 PST 2014


On Saturday, 18 January 2014 at 01:58:13 UTC, Walter Bright wrote:
> I strong, strongly, disagree with the notion that critical 
> systems should soldier on once they have entered an invalid 
> state. Such is absolutely the wrong way to go about making a 
> fault tolerant system. For hard evidence, I submit the safety 
> record of airliners.

But then you have to define "invalid state", not in terms of 
language constructs, but in terms of the model the implementation 
is based on.

If your thread only uses thread local memory and safe language 
features it should be sufficient to spin down that thread and 
restart that sub-service. That's what fault tolerant operating 
systems do.

In a functional language it is easy, you may keep computing with 
"bottom" until it disappears. "bottom" OR true => true, "bottom" 
AND false => false. You might even succeed by having lazy 
evaluation over functions that would never halt.

If you KNOW that a particular type is not going to have any 
adverse affect if taking a default object rather than null (could 
probably even prove it in is some cases), it does not produce an 
"invalid state". It might be an exceptional state, but that does 
not imply that it is invalid.

Some systems are in an pragmatic fuzzy state. Take fuzzy logic as 
an example (http://www.dmitry-kazakov.de/ada/fuzzy.htm) where you 
operate with two fluid dimensions: necessity and possibility, 
representing a space with the extremes: false, true, 
contradiction and uncertain. There is no "invalid state" if the 
system is designed to be in a state of "best effort".


More information about the Digitalmars-d mailing list