Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Shane Sendall (sendall@acm.org)
Date: Tue 18 May 2004 - 08:24:38 BST


Hi,
Comments embedded below.
John Daniels wrote:

>Hi Shane,
>  
>
>>HOWEVER, the question arises as to when this situation could arise,
>>because (as far as I know) OclUndefined can never really be "assigned" 
>>to anything (it is not the same as null or nil in programming 
>>languages): it simply makes the overall expression undefined (except for 
>>some special cases of lazy evaluation).
>>So if you could say p is initialized to some expression that is 
>>undefined then you would run across this problem. However, I do not 
>>think that this is possible in OCL (for the reason given above).
>>So I guess my question is whether my statement about OclUndefined is 
>>correct. If it is correct, then maybe there is really no (practical) 
>>problem after all...
>>    
>>
>
>I realise that OclUndefined can't be "assigned" to anything, but it's
>trivial to imply that it has been:
>
>p : Integer
>q : Boolean
>
>inv: q implies p = OclUndefined
>
The intention of OCL is that you use oclIsUndefined(), i.e.,
inv: q implies p.oclIsUndefined()
After checking out the definition of oclIsUndefined(), it looks like you 
are still correct (pp. 149 of spec):
  oclIsUndefined() : Boolean
  Evaluates to true if the self is equal to OclUndefined.
  post: result = self.isTypeOf( OclVoid )

Looks to me like we have one for the OCL revision laundry list...
Clearly this is not a severe problem, but nevertheless one worth fixing IMO.

Cheers,
    Shane

Date view Thread view Subject view Author view Attachment view