Attached types - Revision history

Peter gummer: /* Introduction */

2007-04-18T03:05:20Z

‎Introduction

Alexander Kogtenkov: /* Automation */ Cosmetics

2007-04-10T12:56:33Z

‎Automation: Cosmetics

Alexander Kogtenkov: /* Suggested Attachment Pattern (SAP) */ Cosmetics

2007-04-10T12:53:41Z

‎Suggested Attachment Pattern (SAP): Cosmetics

Alexander Kogtenkov: /* Introduction */ Cosmetics

2007-04-10T12:48:37Z

‎Introduction: Cosmetics

Alexander Kogtenkov: /* Void-safety levels */ Added initial description

2007-04-10T12:43:39Z

‎Void-safety levels: Added initial description

Alexander Kogtenkov: /* Automation */ Added initial description

2007-04-10T12:09:38Z

‎Automation: Added initial description

Alexander Kogtenkov: /* Suggested Replacement Pattern (SRP) */ Added description

2007-04-10T06:08:44Z

‎Suggested Replacement Pattern (SRP): Added description

Alexander Kogtenkov: Started initial page on attached types

2007-04-09T20:27:56Z

Started initial page on attached types

New page

[[Category: Compiler]]
[[Category: ECMA]]
=== Introduction ===
Attached types are introduced in the language by the ECMA/ISO standard to get rid of a common program error caused by a call of a feature on a Void target. The existing code base cannot be changed overnight to follow the new safety standards. Therefore there is a task to perform the smooth transition from non-void-safe code to void-safe code. This can be done by systematic application of the following steps:
# '''Identification.''' The code is analyzed to find some common patterns that assume that the target of the feature call is not void. They can be explicit, such as
<e>
require
a /= Void
</e>
as well as implicit, such as
<e>
a.f
</e>
# '''Selection.''' Usually there is more than one way to change the existing code to make it void-safe. The correct replacement depends on the semantics of the piece of code and may rely on expert knowledge of a user. But there are still many "common" cases that require the same kind of modification which allows for automation of the process.
# '''Modification.''' After selection among the possible variants is completed, the actual code modification is performed. In order to avoid breaking all the code, the backup of the original as well as a journal of the changes can be kept.
The steps above can be performed manually, semi-automatically or automatically. The sections below discuss the variants that involve the tools to automate the transition to void-safe code.
=== Suggested Attachment Pattern (SAP) ===
Suggested Attachment Pattern (SAP) in non-void-safe code is similar to Certified Attachment Pattern (CAP) in void-safe code. Moreover, SAP is a superset of CAP, i.e. it includes all CAP code snippets as well as some other variants. SAP stands for the code patterns that expect that there is no feature calls on void target if they themselves do not trigger any exception. The most simple SAP includes the condition <e>x /= Void</e>. In this case the type of <e>x</e> can be declared to be attached, so that the condition can be optimized by substituting the value <e>True</e>, or non-attached, so that the condition is not affected.
{|
! SAP
|-
| <e>require x /= Void</e>
|-
| <e>ensure x /= Void</e>
|-
| <e>invariant x /= Void</e>
|}
=== Suggested Replacement Pattern (SRP) ===
=== Automation ===
=== Void-safety levels ===

@@ Line 52: / Line 52: @@
 # Make suggested replacements asking each time
 #* interactively
-#* by using a check list mentioned in the previous point
+#* by using a check list mentioned above
 # Make suggested replacements automatically without human intervention
 #* perform all possible replacements

← Older revision		Revision as of 12:43, 10 April 2007
Line 58:		Line 58:

	=== Void-safety levels ===		=== Void-safety levels ===
		+	The compiler can be instructed to apply void safety rules on different scopes:
		+	* system/library
		+	* cluster
		+	* class
		+	This is achieved by the appropriate configuration options. In practice, a single system might use clusters with different settings for void safety. Then additional care should be taken on the boundaries to avoid compromizing void-safe classes by non-void-safe ones.
		+
		+	The compiler options also allow to control the level of the void safety checks:
		+	{\| border="1" cellspacing="0"
		+	\| rowspan="2" align="center" \| Level
		+	\| colspan="2" align="center" \| Are attachment properties checked at
		+	\|-
		+	\| align="center" \| compile-time?
		+	\| align="center" \| run-time?
		+	\|-
		+	! align="left" \| Compatibility mode
		+	\| align="center" \| no
		+	\| align="center" \| yes (workbench) / no (finalized)
		+	\|-
		+	! align="left" \| Dynamic safety
		+	\| align="center" \| yes, if possible
		+	\| align="center" \| yes, unless proven at compile-time
		+	\|-
		+	! align="left" \| Static safety
		+	\| align="center" \| yes (error unless proven)
		+	\| align="center" \| no
		+	\|}

← Older revision		Revision as of 12:09, 10 April 2007
Line 45:		Line 45:

	=== Automation ===		=== Automation ===
		+	The process of applying SRP for SAP can be automated. It can be integrated into [[:Category:EiffelStudio\|EiffelStudio]] or run as a separate tool. The following actions can be provided:
		+	# List all suggested replacements. The variants of this facility include:
		+	#* display the list on the screen
		+	#* log it to a file
		+	#* prepare a check list for further analysis by a user
		+	# Make suggested replacements asking each time
		+	#* interactively
		+	#* by using a check list mentioned in the previous point
		+	# Make suggested replacements automatically without human intervention
		+	#* perform all possible replacements
		+	#* perform replacements only for the selected SAPs
		+
	=== Void-safety levels ===		=== Void-safety levels ===

@@ Line 2: / Line 2: @@
 [[Category: ECMA]]
 === Introduction ===
-Attached types are introduced in the language by the ECMA/ISO standard to get rid of a common program error caused by a call of a feature on a Void target. The existing code base cannot be changed overnight to follow the new safety standards. Therefore there is a task to perform the smooth transition from non-void-safe code to void-safe one. This can be done by systematic application of the following steps:
+Attached types are introduced into the language by the ECMA/ISO standard to get rid of a common program error caused by a call of a feature on a Void target. The existing code base cannot be changed overnight to follow the new safety standards. Therefore there is a task to perform the smooth transition from non-void-safe code to void-safe code. This can be done by systematic application of the following steps:
 # '''Identification.''' The code is analyzed to find some common patterns that assume that the target of the feature call is not void. They can be explicit, such as
 <e>

@@ Line 18: / Line 18: @@
 === Suggested Attachment Pattern (SAP) ===
 Suggested Attachment Pattern (SAP) in non-void-safe code is similar to Certified Attachment Pattern (CAP) in void-safe code. Moreover, SAP is a superset of CAP, i.e. it includes all CAP code snippets as well as some other variants. SAP stands for the code patterns that expect that there is no feature calls on void target if they themselves do not trigger any exception. The most simple SAP includes the condition <e>x /= Void</e>. In this case the type of <e>x</e> can be declared to be attached, so that the condition can be optimized by substituting the value <e>True</e>, or non-attached, so that the condition is not affected.
-{|
-! SAP
+Examples of SAP:
-|-
+<e>
-| <e>require x /= Void</e>
+require x /= Void
-|-
+ensure x /= Void
-| <e>ensure x /= Void</e>
+invariant x /= Void
-|-
+</e>
-| <e>invariant x /= Void</e>
-|}
 === Suggested Replacement Pattern (SRP) ===
 Consider the following code snippet:

@@ Line 27: / Line 27: @@
 |}
 === Suggested Replacement Pattern (SRP) ===
 === Automation ===
 === Void-safety levels ===