Manus: Cosmetics

2009-04-14T20:08:18Z

Cosmetics

Alexander Kogtenkov: Added a page describing void safety option

2009-04-14T09:26:31Z

Added a page describing void safety option

New page

Project configuration allows assigning the void safety status for the selected set of classes. In order to facilitate the migration of the existing code to meet the standard requirements, different levels of void safety can be used. They are described in the sections below. The validity rules that are affected by the void safety settings include 3 different sets:
# VUTA - target of a feature call should be attached
# VEVI - entity of an attached type should be properly set before use
# VJAR and family - attachment status is taken into account when checking type conformance
Depending on the requested void safety level different validity rules are involved in checks.
== Compatibility - ''none'' (no void safety) ==
No void safety checks are performed.
== Standard - ''all'' (complete void safety) ==
All void safety checks are performed.
== On-demand - ''initialization'' (selective void safety) ==
Some void safety checks are performed. Let's consider the validity rules listed above to see what are the dependencies among them. First, VUTA relies on the property of entities of an attached type to be really attached before they are used. In other words, VUTA checks are sound only when VEVI checks are performed. For example,
<e>local
a: attached ACCOUNT
do
a.deposit (amount) -- Does not make sense to check VUTA here because VEVI is not satisfied
...
end</e>
On the other hand, VEVI validity rules cannot be ensured if attachment status is not taken into account when performing conformance checks. For example,
<e>check_account (account: detachable ACCOUNT)
local
a: attached ACCOUNT
do
a := account -- Does not make sense to check VEVI here because VJAR is not satisfied
...
end</e>
So, the ''on-demand'' void safety ensures that attached entities are properly set and takes attachment status into account when checking type conformance.
[[Category:Compiler]][[Category:Configuration]][[Category:ECMA]]

@@ Line 13: / Line 13: @@
 	a: attached ACCOUNT
 do
-	a.deposit (amount) -- Does not make sense to check VUTA here because VEVI is not satisfied
+		-- Does not make sense to check VUTA here because
 	...
 end</e>
@@ Line 21: / Line 23: @@
 		a: attached ACCOUNT
 	do
-		a := account -- Does not make sense to check VEVI here because VJAR is not satisfied
+			-- Does not make sense to check VEVI here
 		...
 	end</e>
 So, the ''on-demand'' void safety ensures that attached entities are properly set and takes attachment status into account when checking type conformance.
 [[Category:Compiler]][[Category:Configuration]][[Category:ECMA]]

Void-safe Option - Revision history

Manus: Cosmetics

Alexander Kogtenkov: Added a page describing void safety option