Difference between revisions of "Transient Attributes"
(→Validity Rule) |
|||
Line 13: | Line 13: | ||
== Validity Rule == | == Validity Rule == | ||
An attribute can be marked `volatile' if and only if: | An attribute can be marked `volatile' if and only if: | ||
− | # its type has a default value | + | # its type has a default value (i.e. it cannot be a formal or an attached type) |
# it is not a user defined expanded type | # it is not a user defined expanded type | ||
# the enclosing class is not expanded | # the enclosing class is not expanded |
Revision as of 11:31, 24 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:
- its type has a default value (i.e. it cannot be a formal or an attached type)
- it is not a user defined expanded type
- 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.