Difference between revisions of "Transient Attributes"

(Rationale of validity rule)
Line 10: Line 10:
  
 
== Validity Rule ==
 
== Validity Rule ==
An attribute can be marked `volatile' if and only if its type has a default value and is not a user defined expanded type.
+
An attribute can be marked `volatile' if and only if:
 +
# its type has a default value
 +
# it is not a user defined expanded type
 +
# the enclosing class is not expanded
  
 
== Rationale of validity rule ==
 
== Rationale of validity rule ==
 
If the type did not have a default value (which is the case for attached types), then upon retrieval the volatile attribute would be Void which is against void-safety.
 
If the type did not have a default value (which is the case for attached types), then upon retrieval the volatile attribute would be Void which is against void-safety.
  
For simplicity and backward compatibility of `basic_store' which does a memory copy of the object to disk, it would be quite complicated to implement when user expanded are marked volatile. We prefer our users to use SED once it supports expanded which will easily support the notion of volatile expanded attributes.
+
For simplicity and backward compatibility of `basic_store' which does a memory copy of the object to disk, it would be quite complicated to implement when expanded are involved. We prefer our users to use SED once it supports expanded.

Revision as of 15:16, 23 June 2009

For storable purposes, it makes sense that some attributes of objects are not stored to disk. We call them volatile attribute and currently are specified using a note clause:

field: detachable X
   note
     option: volatile
   attribute
   end

Validity Rule

An attribute can be marked `volatile' if and only if:

  1. its type has a default value
  2. it is not a user defined expanded type
  3. the enclosing class is not expanded

Rationale of validity rule

If the type did not have a default value (which is the case for attached types), then upon retrieval the volatile attribute would be Void which is against void-safety.

For simplicity and backward compatibility of `basic_store' which does a memory copy of the object to disk, it would be quite complicated to implement when expanded are involved. We prefer our users to use SED once it supports expanded.