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:32:42 BST


Hi Shashank,
Maybe I misunderstood your problem, but I can't see how you can decide 
whether the hash code is any good or not without a comparison. From this 
condition, you can decide what you want to assert. Here is some code 
(note that I have simplified things by passing the serialized hash code 
as a  parameter).
context MyClass::readSerialized(serializedHash: HashCode)): MyClass
post: if serializedHash = self.hashCode() then
            result = ...
         else
            result = ...
         endif

I hope that helps... (I probably misunderstood though)

Cheers,
    Shane


Shashank wrote:

>Hi Shane,
>
>Lets suppose I get a serialized object.
>
>Now I have a list of hash codes of objects with different states of same class).
>
>Now when I try to compare hash value of object read from serialized object, and
>compare that with existing hash codes it may fail, as the object may have
>different state!!. And if this happens then I need to take care against possible
>commission fault. And I want to set the state of some object to something.
>
>Now how do I model following requirement
>if serialized object is not valid  then set state of some object to something.
>
>Can I use OCL to model that using oclUndefined
>
>context MyClass : readSerialized() :
>        let hash :HashCode = self.getObject () in
>        if hash.oclIsUndefined() then
>        result = this;
>    else
>        result = that;
>    end if
>
>
>In the above scenario oclIsUndefined()  (Undefined because the hash code created
>doesn't matches with existing list of hash code  (Meaning object (serialized
>objects) definition is not available to me?)
>
>Is that correct usage of undefined? and correctly distinguishes from the context
>of its usage that we are discussing.
>
>Shane Sendall wrote:
>
>  
>
>>Hi Laurie,
>>It is interesting that you differentiate between "never been
>>initialized" and "uninitialized". Can you whet our appetitte further by
>>giving us some examples of where you use this, i.e., some motivating
>>examples?
>>
>>Thanks,
>>    Shane
>>Laurence Tratt wrote:
>>
>>    
>>
>>><snip>
>>>Most languages that I am aware of do not, at the user level, differentiate
>>>between "this value has NULL assigned to it" and "this value is undefined" -
>>>NULL is all that is given to the user. Note that I am aware of several
>>>languages which *internally* have a way of noticing that certain variables
>>>and slots have not yet been assigned to, but there's no way for the user to
>>>test for this other than causing an exception to be generated. Certainly, my
>>>own Converge language follows in these footsteps, so that I can detect
>>>people attempting to read from variables before they have been assigned an
>>>initial value. Once an initial value has been assigned (be it NULL or
>>>anything else), it is impossible for the variable to return to the
>>>"undefined" state.
>>>
>>>Yours,
>>>
>>>
>>>Laurie
>>>
>>>
>>>      
>>>
>>To remove yourself from this list please mail puml-list-request@cs.york.ac.uk
>>with a message containing the word "unsubscribe".
>>    
>>
>
>
>
>
>To remove yourself from this list please mail puml-list-request@cs.york.ac.uk
>with a message containing the word "unsubscribe".
>
>  
>

Date view Thread view Subject view Author view Attachment view