From: Jörn Guy Süß (email@example.com)
Date: Wed 19 May 2004 - 08:53:58 BST
Dear Shane, I agree with Laurence that using NULL to signify indicision, absence, optionality, lack of initialisation or what have you is a bad concept. It seems this discussion is reliving the age old "what is that NULL in my database"-argument. Effectively, I believe that assigning a NULL value is a short-hand for unfinished design. This becomes evident in the "specializations" that value develops during such discussions: MyUndecidedNULL, MyIinformationIsLackingNull, MyICanFillItInMySelfNULL, MyThisIsNotReadyYetNULL etc. pp. I see the point of leaving some non-essential issues open while exploring the essential features in modeling. But that looseness should IMO not be turned into a virtue in itself. One ends up with a non-boolean logic which is incompatible with standard math and makes transfers hard and awkward. It is like dropping the whole logic/inference/reaoning library from our palette of available components just because we cannot come to a decision on a type structure or the meaning of some model element. So we invent our own. I see this as bad reuse. What was OO about, again? So I think, keeping NULL out of models (and OCL-constraints) as soon as we leave the sketching phase would be my prefered way of dealing with the situation. Sorry about this rave, but I have seen a great many NULLs passed, returned and stored, and quite a few of them caused problems. Kind regards, Jörn Guy Süß Dipl.-Inform. Jörn Guy Süß | CIS - Sekr. EN7 phone / fax : +49(30) 314-23553/21601 | TU Berlin, Fak IV phone (secretary) : +49(30) 314-23555 | Einsteinufer 17 mailto:firstname.lastname@example.org | D-10587 BERLIN / GERMANY -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Laurence Tratt Sent: Tuesday, May 18, 2004 11:09 PM To: email@example.com Subject: Re: Optional attributes On Tue, May 18, 2004 at 10:00:45PM +0200, Shane Sendall wrote: Dear Shane, > Certainly from a language definition point of view. 'null' as meaning the > absence of a value is the most elegant, because IMO this is the real > reason/meaning for 'null'. One must be careful not to confuse the standard English meaning of a word with the concept it represents in a given context. I have some sympathy for the Python approach where they called the keyword None which gets rid of the "ooo, null means there must be nothing there" problem. My take on this is that it doesn't make sense to expose directly to the user the concept of the absence of a value. In a pure OO system, if you have NULL as a special object (or some means of uniquely identifying it), you can achieve all that you can if NULL is implied by the absence of a value. However, if NULL is present merely by its absence then what happens in e.g. a statement like "print(NULL)" (or whatever)? Answer: the print function now has to explicitly know about NULL, because it can't call a "toStr()" method when there is no object present! Basically if you make NULL be the absence of a value, you start having to encode knowledge of NULL into places that could otherwise have remained blissfully ignorant of it. It's a very non object orientated decision which can end up merrily biting people on the arse in perpetuity. Yours, Laurie -- http://tratt.net/laurie/ To remove yourself from this list please mail firstname.lastname@example.org with a message containing the word "unsubscribe".