Transient Attributes - Revision history

Manus: Renamed volatile into transient

2009-07-06T16:20:31Z

Renamed volatile into transient

Manus: Volatile Attributes moved to Transient Attributes: Better naming of mechanism

2009-07-06T16:19:42Z

Volatile Attributes moved to Transient Attributes: Better naming of mechanism

Manus at 15:07, 1 July 2009

2009-07-01T15:07:56Z

Manus: /* Validity Rule */

2009-06-24T19:31:29Z

‎Validity Rule

Manus at 18:57, 24 June 2009

2009-06-24T18:57:54Z

Manus at 23:16, 23 June 2009

2009-06-23T23:16:35Z

Manus: /* Rationale of validity rule */

2009-06-23T22:47:22Z

‎Rationale of validity rule

Manus: /* Validity Rule */

2009-06-23T22:46:16Z

‎Validity Rule

Manus at 22:37, 23 June 2009

2009-06-23T22:37:37Z

Manus: New page: 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: deta...

2009-06-23T22:34:45Z

New page: 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: deta...

New page

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 and if the enclosing class is not expanded.

@@ Line 1: / Line 1: @@
 [[Category:Compiler]]
 [[Category:Runtime]]
-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:
+For storable purposes, it makes sense that some attributes of objects are not stored to disk. We call them transient attribute and currently are specified using a note clause:
 <e>
   field: detachable X
     note
-      option: volatile
+      option: transient
     attribute
     end
@@ Line 12: / Line 12: @@
 == Validity Rule ==
-An attribute can be marked `volatile' if and only if:
+An attribute can be marked `transient' 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
@@ Line 18: / Line 18: @@
 == 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 transient 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.
 == Semantic ==
-The volatile property of an attribute declared in a class A keeps its volatile property in descendants of A unless the attribute is redefined.
+The transient property of an attribute declared in a class A keeps its transient property in descendants of A unless the attribute is redefined.

← Older revision		Revision as of 15:07, 1 July 2009
Line 21:		Line 21:

	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.		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.
		+
		+	== Semantic ==
		+	The volatile property of an attribute declared in a class A keeps its volatile property in descendants of A unless the attribute is redefined.

@@ Line 13: / Line 13: @@
 == Validity Rule ==
 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
 # the enclosing class is not expanded

← Older revision		Revision as of 18:57, 24 June 2009
Line 1:		Line 1:
		+	[[Category:Compiler]]
		+	[[Category:Runtime]]
	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:		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:

@@ Line 10: / Line 10: @@
 == 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:
 == 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 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.

← Older revision	Revision as of 16:19, 6 July 2009
(No difference)

← Older revision		Revision as of 22:47, 23 June 2009
Line 15:		Line 15:
	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 expanded are ~~involved~~. We prefer our users to use SED once it supports expanded.	+	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.