Author:halw

Date:2008-09-28T19:35:05.000000Z


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

documentation/current/_templates/Rule.tpl

@@ -0,0 +1 @@
+<p style="margin-left: 10px; margin-right: 50px; border: 1px solid #0a427d; padding: 10px; background-color: #eef7fb; color: black;">[[Image:LogoInformation|24px]] '''Rule -- {{{1}}}:''' {{{2}}}</p>

documentation/current/_templates/Rule.tpl.data

@@ -0,0 +1,3 @@
+title=Rule
+author=admin
+path=content/rule

documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki

@@ -11,15 +11,15 @@ A system -- a software system in particular, but the ideas are more general -- i
 An Eiffel contract is similar to a real-life contract between two people or two companies, which it is convenient to express in the form of tables listing the expectations and guarantees. Here for example is how we could sketch the contract between a homeowner and the telephone company:
 {| border="1"
 |- 
-| <code>provide_service</code>|| style="width=10%"
+| style="width=10%" |provide telephone service 
-| '''OBLIGATIONS'''|| style="width=35%"
+| style="width=35%" |'''OBLIGATIONS'''
-| '''BENEFITS'''|| style="width=35%"
+| style="width=35%" |'''BENEFITS'''
 |- 
 |   '''Client''' 
 |  (Satisfy precondition:) <br/>
 Pay bill. 
 |  (From postcondition:) <br/>
-Get telephone service Supplier. 
+Receive telephone service from Supplier. 
 |- 
 |   '''Supplier''' 
 |  (Satisfy precondition:) <br/>
@@ -95,9 +95,9 @@ The postcondition of a routine expresses what the routine guaranteed to its clie
 The precondition and postcondition state the terms of the contract between the routine and its clients, similar to the earlier example of a human contract:
 {| border="1"
 |- 
-| <code>deposit</code>|| style="width=10%;"
+| style="width=10%" |<code>deposit</code>
-| '''OBLIGATIONS'''|| style="width=35%;"
+| style="width=35%"| '''OBLIGATIONS'''
-| '''BENEFITS'''|| style="width=35%;"
+| style="width=35%" | '''BENEFITS'''
 |- 
 |   '''Client''' 
 |  (Satisfy precondition:) <br/>

documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki

@@ -78,7 +78,7 @@ The inheritance mechanism is relevant to both roles of classes: module and type.
 
 '''Polymorphic assignment''' supports this second role. In an assignment <code> x := y </code>, the types of <code> x </code> and <code> y </code> do not have, with inheritance, to be identical; the rule is that the type of <code> y </code> must simply '''conform''' to the type of <code> x </code>. A class <code> D </code> conforms to a class <code> A </code> if and only if it is a descendant of <code> A </code> (which includes the case in which <code> A </code> and <code> D </code> are the same class); if these classes are generic, conformance of <code> D </code> <code> [ </code> <code> U </code> <code> ] </code> to <code> C </code> <code> [ </code> <code> T </code> <code> ] </code> requires in addition that type <code> U </code> conform to type <code> T </code> (through the recursive application of the same rules). 
 
-{{note|In addition, it follows from the earlier discussion of tuples ( [[10 Other Mechanisms|"Tuple types", page 90]] ), that <code> TUPLE [X] </code> conforms to <code> TUPLE </code>, <code> TUPLE [X, Y] </code> to <code> TUPLE [X] </code> and so on. }}
+{{note|In addition, it will be shown in the discussion of tuples ([[10 Other Mechanisms|"Tuple types"]]), that <code> TUPLE [X] </code> conforms to <code> TUPLE </code>, <code> TUPLE [X, Y] </code> to <code> TUPLE [X] </code> and so on. }}
 
 So with the inheritance structure that we have seen, the declarations
 <code>
@@ -580,10 +580,7 @@ If there are separate accounts for students' course work and for faculty, you ma
 
 The Eiffel rule enables, once again, the software developer to craft the resulting class so as to tune it to the exact requirements. Not surprisingly, it is based on names, in accordance with the Final Name rule (no in-class overloading):
 
-{{note| '''Repeated Inheritance rule''' <br/>
+{{note| '''Repeated Inheritance rule:''' <br/>A feature inherited multiply under one name will be shared: it is considered to be just one feature in the repeated descendant.<br/>A feature inherited multiply under different names will be replicated, yielding as many variants as names. }}
-* A feature inherited multiply under one name will be shared: it is considered to be just one feature in the repeated descendant. 
-* A feature inherited multiply under different names will be replicated, yielding as many variants as names. 
-}}
 
 So to tune the repeated descendant, feature by feature, for sharing and replication it suffices to use renaming. 
 

documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki

@@ -6,7 +6,7 @@ Eiffel software texts are free-format: distribution into lines is not semantical
 
 Successive declarations or instructions may be separated by semicolons. Eiffel's syntax has been so designed, however, that (except in rare cases) '''the semicolon is optional'''. Omitting semicolons for elements appearing on separate lines lightens text and is the recommended practice since semicolons, as used by most programming languages, just obscure the text by distracting attention from the actual contents. Do use semicolons if you occasionally include successive elements on a single line. 
 
-63 names -- all unabbreviated single English words, except for <code> elseif </code> which is made of two words -- are reserved, meaning that you cannot use them to declare new entities. Here is the list: 
+56 names -- all unabbreviated single English words, except for <code> elseif </code> which is made of two words -- are reserved, meaning that you cannot use them to declare new entities. Here is the list: 
 {| border="1"
 |- 
 | <code>agent</code>

documentation/current/method/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki

@@ -33,9 +33,9 @@ feature
 end -- VEHICLE
 </code>
 
-<code>This example assumes that no single registration algorithm applies to all kinds of vehicle; passenger cars, motorcycles, trucks etc. are all registered differently. But the same precondition and postcondition apply in all cases. The solution is to treat register as a deferred routine, making VEHICLE a deferred class. Descendants of class VEHICLE, such as CAR or TRUCK, effect this routine, that is to say, give effective versions. An effecting is similar to a redefinition; only here there is no effective definition in the original class, just a specification in the form of a deferred routine. The term '''redeclaration''' covers both redefinition and effecting.</code> 
+This example assumes that no single registration algorithm applies to all kinds of vehicle; passenger cars, motorcycles, trucks etc. are all registered differently. But the same precondition and postcondition apply in all cases. The solution is to treat register as a deferred routine, making VEHICLE a deferred class. Descendants of class VEHICLE, such as CAR or TRUCK, effect this routine, that is to say, give effective versions. An effecting is similar to a redefinition; only here there is no effective definition in the original class, just a specification in the form of a deferred routine. The term '''redeclaration''' covers both redefinition and effecting.
  [[Image:invitation-5]]  
-<code> Whereas an effective class described an implementation of an abstract data types, a deferred class describes a set of possible implementations. You may not instantiate a deferred class: create v is invalid if v is declared of type VEHICLE. But you may assign to v a reference to an instance of an effective descendant of VEHICLE. For example, assuming CAR and TRUCK provide effective definitions for all deferred routines of VEHICLE, the following will be valid: </code> 
+Whereas an effective class described an implementation of an abstract data types, a deferred class describes a set of possible implementations. You may not instantiate a deferred class: create v is invalid if v is declared of type VEHICLE. But you may assign to v a reference to an instance of an effective descendant of VEHICLE. For example, assuming CAR and TRUCK provide effective definitions for all deferred routines of VEHICLE, the following will be valid: 
 <code>
 v: VEHICLE; c: CAR; t: TRUCK
 ... create c; create t ...
@@ -54,6 +54,3 @@ Beyond design and implementation, these techniques extend to the earliest stage
 
 Eiffel appears here in its full role of a lifecycle approach, covering areas traditionally considered separate: program implementation, the traditional province of development environments; system modeling and architecture, the traditional province of CASE tools based on UML or similar notations disconnected from the rest of the lifecycle. Eiffel instead emphasizes the fundamental unity of the software process and the usefulness of a single set of notations, concepts and tools applicable throughout. Such a seamless approach is indispensable to support the inevitable reversals that occur during the process of building software, such as detecting at implementation time a problem that leads to a change in the system's functionality, set at analysis time. The use of separate tools and notations, such as UML on one side and a programming language on the other, makes such round-trips difficult at best and often leads to monolithic, hard-to-change software. Eiffel lets you focus on the issues, without interposing artificial barriers between different software development activities. You'll use the fundamental problem-solving techniques -- data abstraction through classes, precise specification through contracts, modularity through information hiding, rational organization through inheritance, decentralized architecture through dynamic binding, parameterization of the solution through genericity, reusability through all these techniques -- all along; only the level of abstraction changes.
 
-
-
-

documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/referenced-assembly-type-and-feature-name-conversion.wiki

@@ -1,7 +1,7 @@
 [[Property:title|Referenced Assembly Type and Feature Name Conversion]]
 [[Property:weight|10]]
 [[Property:uuid|5d575090-35d9-f983-7308-172b1641173f]]
-The [[The Eiffel for .NET language|Eiffel for .NET language]]  is Eiffel. It is not a variant of Eiffel that spawned a new language, as is '''C#''', or a dramatic evolution of Eiffel, such as '''Visual Basic .NET''' is to '''VB6'''. As Eiffel stands today, and will probably remain, Eiffel's conventions for class names and features names do not match that of the Pascal and Camel-casing conventions recommended by Microsoft. Eiffel also does not support the notion of full quantified type names. The period (''''.'''') between namespace and type names is not valid Eiffel syntax. These naming convention rules pose a problem for maintaining the Eiffel language. To address this issue, when referencing .NET assemblies, all referenced assembly type names and feature names are converted into "Eiffel-case" when using Eiffel. 
+The [[The Eiffel for .NET language|Eiffel for .NET language]]  is Eiffel. It is not a variant of Eiffel that spawned a new language, as is '''C#''', or a dramatic evolution of Eiffel, such as '''Visual Basic .NET''' is to '''VB6'''. As Eiffel stands today, and will probably remain, Eiffel's conventions for class names and features names do not match that of the OO Pascal variants and the "Camel-casing" conventions recommended by Microsoft. Eiffel also does not support the notion of full quantified type names. The period (''''.'''') between namespace and type names is not valid Eiffel syntax. These naming convention rules pose a problem for maintaining the Eiffel language. To address this issue, when referencing .NET assemblies, all referenced assembly type names and feature names are converted into "Eiffel-case" when using Eiffel. 
 <span id="eiffel_case"></span> 
 ==What is Eiffel-Case?==
 
@@ -10,7 +10,7 @@ Eiffel-casing is almost the same for both class and class feature names, all wor
 <eiffel>MY_CLASS</eiffel> is an example of an Eiffel-cased class name. <br/>
 <eiffel>my_feature</eiffel> is an example of an Eiffel-cased feature name. 
 
-There are complex rules to ensure that the automatic formatting of .NET name, type, method, property and otherwise are formatted to the most readable name possible, given their casing convention. One absolute is that the Eiffel compilation process will remove the namespace from the fully qualified type name and format just the type name. 
+There are somewhat complex rules to ensure that the automatic formatting of .NET name, type, method, property and otherwise are formatted to the most readable name possible, given their casing convention. One absolute is that the Eiffel compilation process will remove the namespace from the fully qualified type name and format just the type name. 
 
 For example <eiffel>System.Windows.Forms.Border3DStyle</eiffel> would yield <eiffel>BORDER_3D_STYLE</eiffel>. 
 

documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel.wiki

@@ -183,7 +183,7 @@ In particular all tuple types conform to [[ref:/libraries/base/reference/tuple_c
 	to a type T, then TUPLE [T1, T2, ..., Tn] conforms
 	to [[ref:/libraries/base/reference/array_chart|ARRAY]]  [T].</code>
 
-Definition: a "tuple type" is any type based on class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , i.e. any type of the form [[ref:/libraries/base/reference/tuple_chart|TUPLE]]  [T <code>1</code>, T <code>2</code>, ..., T <code>n</code>] for any n (including 0, for which there is no generic parameter). 
+{{Definition|Tuple Type|A "tuple type" is any type based on class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , i.e. any type of the form <code>TUPLE</code>  [T <code>1</code>, T <code>2</code>, ..., T <code>n</code>] for any n (including 0, for which there is no generic parameter). }}
 
 {{note|(Note 1: CONF1 should be understood in terms of the underlying mathematical model. Mathematically, [[ref:/libraries/base/reference/tuple_chart|TUPLE]]  [T <code>1</code>, T <code>2</code>, ..., T <code>n</code>] is the set TUPLE <code>n</code> of all partial functions f from N+ (the set of non-negative integers) to T <code>1</code> U T <code>2</code> U ... T <code>n</code>, such that: 
 * The domain of f contains the interval 1..n (in other words, f is defined for any i such that 1 <= i <= n). 

documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/index.wiki

@@ -5,6 +5,3 @@
 
 Learn about the EiffelBase library.
 
-
-
-