Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Shane Sendall (sendall@acm.org)
Date: Wed 19 May 2004 - 09:57:37 BST


Hi Joern,
Just to clarify:
In the context of OCL, what I was referring to as 'null' was simply the 
absence of a value, which may arise for optional "things" like John give 
an example of. This seems useful for modeling.
The rest of the discussion I was flirting with what the concept could 
mean in any language.
I doubt a fully fledged concept of 'null' such as Laurie was talking 
about would be useful for OCL.
As such maybe the operation "oclIsNull" that I was proposing is in fact 
not a good name after all. Maybe a different name, e.g., 
"oclHasNoValue", would be better (as you can see I'm not very good at 
giving names to things :-) )

Cheers,
     Shane



Jrn Guy S wrote:

>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,
>
>Jrn Guy S
>
>Dipl.-Inform. Jrn 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:jgsuess@cs.tu-berlin.de        | D-10587 BERLIN / GERMANY
> 
>
>-----Original Message-----
>From:	puml-list-request@cs.york.ac.uk [mailto:puml-list-request@cs.york.ac.uk] On Behalf Of Laurence Tratt
>Sent:	Tuesday, May 18, 2004 11:09 PM
>To:	puml-list@cs.york.ac.uk
>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
>  
>

Date view Thread view Subject view Author view Attachment view