Peter Gummer wrote:
> Thomas Beale wrote:
> > I did mean to say void-safe. The problem remains: class models, seen as
> > classificatory ontologies of real world concepts (i.e. what we usually
> > call business objects) can't easily be made void-safe because the
> > classifications (things such as PERSON, ACCOUNT) are generally quite
> > broad, and encompass many variations where certain attributes may be
> > void, more or less arbitrarily.
> This doesn't prevent void-safety. Wherever there is the possibility of
> 'x' being void, you simply protect access to it with "if x /= Void" or
> "require x /= Void" or "check x /= Void", or with an object test.
I think my main point here is that half the code in a typical business
information system should be compiled with void-safe types as the
default, while the other half should not. Currently, as far as I can
see, we would have to go and change all the type declarations in
business classes from T to ?T, since void-safe compiling applies
globally, not on a per-cluster or subsystem basis. Or else we just keep
void-safe checking turned off, in which case the advantages in the base
libraries are not used.