headers
Thomas Beale | 1 Feb 2009 01:59

Re: Getting rid of "Void"?

Peter Gummer wrote:
 >
 > Thomas Beale wrote:
 > > Re: the Hoare paper, it only applies to generic computing 
structures, it
 > > does not apply conveniently to business objects, which are also
 > > expressed in the same computing languages. This is because business
 > > objects have many 'optional' elements, and to make models of them in a
 > > Void-less way would create a horrible and unusable type model. I agree
 > > that the base libraries and other similar computing libraries should be
 > > Void-safe, but large application systems will have many business
 > > objects, for which there is no hope of being Void-safe. Realistic
 > > systems will have to allow both kinds of libraries.
 > >
 >
 > I think you're confusing the term "void-safe" with "void-less", Thomas.
 > A system may be void-safe while still using "void" extensively.
 >

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.

- thomas beale

------------------------------------
(Continue reading)

Permalink | Reply |
headers
Peter Gummer | 1 Feb 2009 02:05
Picon

Re: Getting rid of "Void"?

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.

- Peter Gummer

------------------------------------
Permalink | Reply |
headers
Thomas Beale | 1 Feb 2009 13:37

Re: Getting rid of "Void"?

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.

- thomas

------------------------------------
(Continue reading)

Permalink | Reply |

Gmane