NULLs

[Hans-Dieter.Dreier@materna.de]

--ChvRtRexp8smkycWO3l1k6yGDWrbnahn
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


NULLs
=3D=3D=3D=3D=3D

Often there is a situation where a special value is needed that expresses t=
he fact that there is "no" value.
Examples include NULL pointers in C, "skip" values in Algol68, "NANs" (Not-=
A-Number) in arithmetics, NULL in SQL.

They share the following common characteristics:

1. There is only one such value (no multiple instances).
2. It can show up whereever a value of the underlying types is expected (po=
inter, any value, numbers), but ...
3. ... it is a type of its own, therefore ...
4. ... only a restricted set (if any) of the operations possible for the un=
derlying type(s) is allowed for it.

NULLs are very convenient but they also introduce some problems:

1. They do not fit nicely into a statical type system.
2. They require (runtime) checks whereever they can appear in order to ensu=
re that no invalid operations are performed on them.

The solutions C++ uses look somewhat unsatisfactory to me:
One is only applicable to reference types (which may be either pointers, X*=
, allowing NULLs, or references, X&, disallowing them),
the other (union and casts) depend on correct handling by the programmer an=
d may cause crashes that the compiler cannot detect.

To me, problem #1 seems to call for something like a "union" of types,
where an object may be of any of a number of otherwise unrelated types and =
the compiler sees to it that no invalid operations can happen.
More specifically, only operations are allowed that are legal for the most =
derived type that is a common ancestor of all the possible types of the val=
ue in question.

Problem #2 is IMO best avoided by forbidding this situation.

Somehow like this:

A, B: aUnion			// object named aUnion may be an A or a B

... to be used like this:

if aUnion.classOf =3D=3D A // classOf is allowed for any object
  then <do something> // here compiler knows aUnion is an A
  else <do something else> // here compiler knows it is something else, in =
this case it must be a B

IOW, you cannot use aUnion as an A unless you make sure (by a contional) it=
 really *is* an A.


Another possibility would be to make sure that an exception is raised if an=
 invalid operation takes place,
but performing a type check each time (to make sure the exception is raised=
) is likely to be too slow.

Any ideas or comments?


--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--ChvRtRexp8smkycWO3l1k6yGDWrbnahn
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a23070a.txt IA5 DX-MAIL X.400 User Agent=

--ChvRtRexp8smkycWO3l1k6yGDWrbnahn--