Author:halw

Date:2010-06-30T14:03:41.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@636 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/eiffelstudio/_images/es_ref_add_attached_contract_template_01.png.data

@@ -0,0 +1,3 @@
+title=es ref add attached contract template 01
+author=halw
+path=content/es-ref-add-attached-contract-template-01

documentation/current/eiffelstudio/_images/es_ref_add_attached_contract_template_02.png.data

@@ -0,0 +1,3 @@
+title=es ref add attached contract template 02
+author=halw
+path=content/es-ref-add-attached-contract-template-02

documentation/current/eiffelstudio/_images/es_ref_contract_editor_add_02.png.data

@@ -0,0 +1,3 @@
+title=es ref contract editor add 02
+author=halw
+path=content/es-ref-contract-editor-add-02

documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-65-and-ise-eiffel-66.wiki

@@ -4,9 +4,10 @@
 [[Property:uuid|4ff759ff-c389-f765-0252-2d844b69fa54]]
 ==What's new==
 {{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
-* Added support for [[ET: Other Mechanisms#Adjusting once semantics with "once keys"|new once syntax and once per object]].
+* Added support for [[ET: Other Mechanisms#Adjusting once semantics with "once keys"|new once syntax and once per object]]. However support for once object is still experimental in this release.
 * Added support for [[ET: Inheritance#Qualified Anchored Declarations|RAT/QAT]], with the following limitations:
 ** Qualified anchored types that involve formal generics with multiple constraints are not supported.
+** When an attribute of type `like a.b.c' yields a formal generic parameter in the chain, then the creation of such attributes would not yield the proper type.
 ** Creation and object tests with the type depending on qualified anchored types that involve deferred intermediate types are not supported on .NET.
 * Added a new option Total Order on REALs which let you have NaN equal to NaN and NaN being the smallest number of all. This option is disabled by default as it could break existing code. The rationale for this option is to have contracts work properly when manipulating the NaN value and not getting spurious contract violation.
 * Added the ability to version a class for storable. It is done via the note clause of a class, i.e. <e>note storable_version: tag</e>. When the storing and retrieving system have a different version a mismatch is triggered even if they look to have the same content.

documentation/current/eiffelstudio/eiffelstudio-reference/contract-editor-tool.wiki

@@ -86,6 +86,55 @@ After editing the assertion clause itself, you can click OK. At this point the C
 At this point, the changes have not been saved to the class text. To save the changes click the Save icon ([[Image:16x16--general-save-icon]]) in the toolbar.
 
 
+=Adding assertion clauses=
+
+You can add a new clause to any contract assertion by clicking the "Add" button ([[Image:16x16--general-add-icon]]) on the toolbar. The button provides two methods of creation "Custom" and "From Template". 
+
+
+[[Image:es ref contract editor add 01|Add Custom or Add from Template]]
+
+
+Choosing "Add Custom..." produces a freeform dialog, much like the editing dialog show earlier in which you can edit an assertion clause from scratch:
+
+
+[[Image:es ref contract editor add 02|Add a custom assertion clause]]
+
+
+"Add from Template" provides a list of code templates for commonly used assertion types. Adding assertion clauses from templates when possible speeds up class specification and helps to avoid errors. Consider a newly coded routine:
+
+<code>
+    my_routine (a_string: STRING)
+            -- Do something with `a_string'.
+        do
+    		
+        end
+</code>
+
+Part of the specification of this routine might be a precondition that states that the argument must be attached (i.e., not <code>Void</code>), and not the empty string. This precondition can be added to the feature by adding two assertion clauses from templates. To specify that <code>a_string</code> must be attached, you would first choose the template "Attached Contract" which provides this dialog:
+
+
+[[Image:es ref add attached contract template 01|Attached contract]]
+
+
+This template focuses on the fact that some entity (expressed as <code>var</code> in the template) must be the object of an assertion clause that guarantees that the entity is attached. To have the template create such a clause for the argument <code>a_string</code> shown in the routine above, just replace  <code>var</code> with <code>a_string</code> in the top text box of the dialog. The resulting code is updated automatically:
+
+
+[[Image:es ref add attached contract template 02|Attached contract]]
+
+
+Adding a clause to specify that <code>a_string</code> must not be empty is done similarly, by selecting the "Not is empty" template. After adding these two precondition clauses, the routine now looks like this:
+
+<code>
+    my_routine (a_string: STRING)
+            -- My routine
+        require
+            a_string_attached: a_string /= Void
+            not_a_string_is_empty: not a_string.is_empty
+        do
+
+        end
+</code>
+