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