[buug] On missing data

Ian Zimmerman itz at speakeasy.org
Mon Dec 2 20:29:47 PST 2002


itz> In type/domain theory, this situation is usually modelled by
itz> adjoining an extra value to the type; that is, by forming a new
itz> type T' that is the disjoint union of the original type T and a
itz> one-element type that represents the absence of proper value.

itz> OOP believers (of which I used to be one) hate this, and will
itz> instead invent a base type of which both Value and Missing are
itz> subtypes, and equip the base type with operations so that users
itz> of the type don't have to distinguish the cases.

Claude> Correct me if I'm wrong, but it seems that both of these
Claude> methods address the issue of missing data in a similar way.
Claude> That is to say, both view the presence of missing data as an
Claude> exceptional event (to echo another discussion on this thread)
Claude> which must be handled "out-of-band" (that is, distinct from
Claude> normal processing).  

Actually, both methods I gave (FP and OOP) are more "in-band" than the
exception approach proposed by Bob.  But in traditional imperative
programming (and in OOP which is closer to it than to FP) the
practical costs of dealing with multiple types are high enough that
the out-of-band/exception method is simpler and therefore preferable.

The costs include both programmer time (having to type the types --
oops -- which you almost never have to do in FP thanks to type
inference) and runtime efficiency (subtyping polymorphism means method
lookup which is always somewhat slower than direct function call).

-- 
Ian Zimmerman, Oakland, California, U.S.A. 
if (sizeof(signed) > sizeof(unsigned) + 4) { delete this; }
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087



More information about the buug mailing list