Author:halw

Date:2009-01-28T16:53:41.000000Z


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

documentation/current/platform-specifics/microsoft-windows/net/building-net-application.wiki

@@ -7,7 +7,7 @@ For that reason, the [[EiffelStudio: Project settings window|project settings]]
 * Specifying whether the generated assembly should be an EXE or a DLL. 
 * Choosing between generating verifiable or non verifiable IL code. Non verifiable IL code executes faster but requires high trust settings. 
 
-The Eiffel for .NET compiler generates a single assembly whose name is the name of the system as given in the [[System Options|project settings]] . 
+The Eiffel for .NET compiler generates a single assembly whose name is the name of the system as given in the [[System Options|system options of the project settings]] . 
 
 
 

documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net-integration.wiki

@@ -23,7 +23,7 @@ Eiffel for .NET supports:
 The following syntax can be used to declare .NET custom attributes on Eiffel entities (features and classes):
 <code>
     empty: BOOLEAN
-        indexing
+        note
             description: "Is Current empty?"
             attribute: create {OBSOLETE_ATTRIBUTE}.make_obsoleteattribute_1 ("Use `is_empty' instead") end
         obsolete
@@ -33,7 +33,7 @@ The following syntax can be used to declare .NET custom attributes on Eiffel ent
         end
 </code>
 
-The previous example shows the declaration of the obsolete feature <code> empty </code> . The custom attribute defined by <code> OBSOLETE_ATTRIBUTE </code> is used to ensure that any consumer of the resulting assembly will see the feature as being obsolete. The custom attribute is defined in the indexing clause <code> attribute </code>. The definition consists of a creation expression that creates the custom attribute with the right parameters. 
+The previous example shows the declaration of the obsolete feature <code> empty </code> . The custom attribute defined by <code>OBSOLETE_ATTRIBUTE</code> is used to ensure that any consumer of the resulting assembly will see the feature as being obsolete. The custom attribute is defined in the <code>note</code> clause <code>attribute</code>. The definition consists of a creation expression that creates the custom attribute with the right parameters. 
 
 ==Differences between Eiffel for .NET and .NET==
 

documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-classes.wiki

@@ -28,7 +28,7 @@ end
 
 Okay, so class SIMPLE is only interesting in its simplicity. Let's look at an example that is more illustrative:
 <code>
-indexing
+note
     description: Objects that model lists
     revision: $Revision: 1.4 $
 
@@ -74,18 +74,18 @@ invariant
     after_constraint: after implies (active = last_element)
 </code>
 Here is a class that, although completely contrived, utilizes all of the required and optional parts of the class. Let's look at each part individually. 
-===Indexing===
+===Note===
 <code>
-indexing
+note
     description: Objects that model lists
     revision: $Revision: 1.4 $
 </code>
 
-The indexing part of a class is there to allow you as a producer to record information of your choice which will help you or other reuse consumers at some later time to locate understand the class. This important in Eiffel because we try to treat every class as if someday it will become reusable. 
+The <code>note</code> part of a class is there to allow you as a producer to record information of your choice which will help you or other reuse consumers at some later time to locate understand the class. This important in Eiffel because we try to treat every class as if someday it will become reusable. 
 
-Information in indexing does not change the semantics of the class.
+Information in <code>note</code> does not change the semantics of the class.
 
-The indexing in the class above is typical. It is introduced with the language keyword <code>indexing</code>, and contains two index clauses, each of which is comprised of an index and a single index value. You can code index clauses with indexes that you devise yourself, so there is nothing inherently special about "<code>description</code>" and "<code>revision</code>" as used above. But, these indexes could be special to tools which analyze libraries of classes use them. Although these clauses have only one index value each, it is permissible to put more, separated by commas. 
+The <code>note</code> part in the class above is typical. It is introduced with the language keyword <code>note</code>, and contains two note clauses, each of which is comprised of an index and a single index value. You can code note clauses with indexes that you devise yourself, so there is nothing inherently special about "<code>description</code>" and "<code>revision</code>" as used above. But, these indexes could be special to tools which analyze libraries of classes use them. Although these clauses have only one index value each, it is permissible to put more, separated by commas. 
 
 ===Class Header===
 <code>
@@ -121,7 +121,7 @@ You will learn more about generic classes in the section titled [[Genericity|Gen
 obsolete "This class is obsolete, use LINKED_LIST [G] instead"
 </code>
 
-<code>OLD_FASHION_LIST</code>s are obsolete ... and the class is marked as such by include the line above. The manifest string contains an explanation, instructions, and/or recommended alternatives. Compilers and other language tools can deliver this message to potential reuse consumers. As with indexing, obsolete has no effect on the semantics of the class. 
+<code>OLD_FASHION_LIST</code>s are obsolete ... and the class is marked as such by include the line above. The manifest string contains an explanation, instructions, and/or recommended alternatives. Compilers and other language tools can deliver this message to potential reuse consumers. As with <code>note</code>, <code>obsolete</code> has no effect on the semantics of the class. 
 
 Obsolete is rarely used because of the nature of certain elements of the Eiffel methodology. For example, if implementations are well-hidden behind implementation-independent specifications, then those implementations may be changed to adapt the class to changing execution environments in such a way that clients are unaffected.