mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-08 07:42:33 +01:00
Code Issues Packages Projects Releases Wiki Activity

Updated trunk

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2484 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eifops
2025-02-06 17:17:32 +00:00
parent dfeab946bd
commit de6e7aad63
89 changed files with 516 additions and 129 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
documentation/trunk/solutions/dotnet/eiffel-net-language/conventions/constructors-and-creation-procedures.wiki Normal file
View File

@@ -0,0 +1,48 @@
[[Property:title|Constructors and Creation Procedures]]
[[Property:weight|4]]
[[Property:uuid|f06eb414-c284-902b-0481-3f00da82d47e]]
This section deals with what happens when objects, that is runtime instances of types, get created and initialized. When a new instance is created, there is an opportunity to initialize the state of the instance. This is done with a constructor in .NET, and with a creation procedure in Eiffel.
==Eiffel Creation Procedures==
Eiffel creation procedures are features of a class which can be used to initialize instances. Classes can have more than one creation procedure available. However, each creation procedure must ensure that the class invariant holds when the procedure completes execution. In other words, the creation procedure is there to initialize a newly created instance, and the class invariant guarantees that a newly initialized instance is actually valid.
There is nothing special about creation procedures themselves, they are just ordinary procedures (although by convention their names usually begin with the word "<code>make</code>"). What makes them creation procedures is the fact that their names are listed as creation procedures in the class text.
In Eiffel, a creation procedure can be applied to an instance at any time (not just at object creation). This is done sometimes to reinitialize existing instances.
==Constructors in .NET==
Like creation procedures in Eiffel, .NET constructors are used to initialize new instances of types. Constructors manifest themselves differently depending upon which .NET language you use. In C#, constructors always appear as a method having the same name as the class on which they are implemented. In Visual Basic .NET, they always appear as a Sub with the name <code>New</code>. Once compiled into an assembly, the metadata labels constructors as <code>. ctor</code>.
Constructors can have multiple versions by overloading. That is, each version would have a different set of argument types.
Constructors can only be applied when a new instance is created.
===Constructors as Eiffel Creation Procedures===
When types from .NET assemblies are made available to Eiffel systems, the constructors are presented as creation procedures. Just as constructors show up in the C# and VB.NET environments with names appropriate to those languages, so it is with Eiffel for .NET. Always, constructors will have feature names which begin with the word "<code>make</code>", the convention for creation procedure naming in Eiffel.
If there is only one version of the constructor, that version will be mapped to a single feature named <code>make</code>. However, if there are overloaded versions of the constructor, then these versions given names starting with "<code>make_from_</code>" and then followed with the argument names from the assembly metadata separated with the conjunction "<code>_and_</code>". Let's look at an example.
The .NET type <code>System.Drawing.Size</code>has an overloaded constructor with two versions. In the <code>System.Drawing</code> assembly metadata, these two constructor versions look like this:
<code>
void .ctor(int32 width, int32 height)
void .ctor(System.Drawing.Point pt)
</code>
So the argument names for the first version are <code>width</code> and <code>height</code>. For the second version there is only one argument named <code>pt</code>. The constructor versions as presented to Eiffel programmers as creation procedures look like this:
<code>
make_from_width_and_height (width: INTEGER; height: INTEGER)
make_from_pt (pt: DRAWING_POINT)
</code>
Presenting the names in this format handles the conflicts of overloading and provides reasonably intuitive names that comply with Eiffel naming conventions.
===Eiffel Creation Procedures as Constructors?===
Eiffel creation procedures do not map to constructors when Eiffel classes are compiled into assemblies. Rather, they are actually manifested as functions on a factory class in the namespace <code lang=text>Create</code> in the assembly. These functions return an initialized instance. In the section Type Organization there is more information about the organization of the types in assemblies built with Eiffel for .NET, along with an example of using types from such an assembly.

220
documentation/trunk/solutions/dotnet/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki Normal file
View File

@@ -0,0 +1,220 @@
[[Property:modification_date|Mon, 25 Sep 2023 09:37:39 GMT]]
[[Property:publication_date|Mon, 25 Sep 2023 09:37:39 GMT]]
[[Property:title|Eiffel Class and Feature Names]]
[[Property:weight|2]]
[[Property:uuid|16e4a231-7aae-4b37-52fd-67876cc222ad]]
Certain naming conventions are respected by Eiffel programmers. Although Eiffel is not case-sensitive, convention dictates the use of upper and lower case in particular situations. When you program in Eiffel for .NET, you create new Eiffel classes, but you also use types from .NET assemblies. These .NET types are presented to you in a view that is consistent with Eiffel conventions.
==Eiffel Class Names==
Convention dictates that Eiffel class names are always all upper case characters with words separated by the underscore ("_") character. Eiffel classes are not qualified by "namespace" as in some other languages. This means that Eiffel class names must be unique with in a system. It also means that any types from existing .NET assemblies will have their names mapped to conventional Eiffel class names in order to be used by Eiffel classes in EiffelEnvision
Here are some class names and their descriptions from the Eiffel Base Library. These class names comply with the Eiffel class naming convention.
<code>
STRING
Sequences of characters, accessible through integer indices in a contiguous range.
RANDOM
Pseudo-random number sequence, linear congruential method.
ARRAYED_LIST
Lists implemented by resizable arrays.
LINKED_QUEUE
Unbounded queues implemented as linked lists.
</code>
Now here are some type names from the .NET mscorlib as they appear as conventional Eiffel class names (i.e. , in the form in which they become available to Eiffel for .NET programmers), followed by their full .NET type and their Summary from the .NET library. names.
<code>
SYSTEM_STRING
System.String
Represents an immutable series of characters.
SYSTEM_RANDOM
System.Random
Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness.
ARRAY_LIST
System.Collections.ArrayList
Implements the System.Collections.IListinterface using an array whose size is dynamically increased as required.
SYSTEM_QUEUE
System.Collections.Queue
Represents a first-in, first-out collection of objects.
</code>
In summary, Eiffel class names and type names from .NET assemblies made available to Eiffel programmers will be all upper case, with words separated by the underscore character.
===Eiffel Names for .NET Types===
How Eiffel compliant names are derived from .NET type names is fairly simple in most cases. The "simple" class name, that is, the word following the rightmost dot in the full class name, is converted to an Eiffel compliant name by making it upper case and separating in embedded words by underscore. In the example above, <code>System.Collection.ArrayList</code> becomes <code>ARRAY_LIST</code>.
The other cases in the example are not quite so simple. If the basic derivation produces a name which conflicts with a classname in the Eiffel Base Library, then it will be disambiguated. The simple derivation of <eiffel>System.String</eiffel> would be <eiffel>STRING</eiffel>, but this would conflict with Eiffel's <eiffel>STRING</eiffel> class, so <eiffel>System.String</eiffel> becomes available to Eiffel for .NET programmers as <eiffel>SYSTEM_STRING</eiffel>.
Sometimes it is better to disambiguate an entire assembly rather than handling individual exceptions to the simple derivation. This is done by specifying a common prefix for all types in the assembly. For example, EiffelEnvision uses a prefix of " <eiffel>DATA_</eiffel>" for all classes in the .NET assembly System.Data. As a result, the type <eiffel>System.Data.Constraint</eiffel> is available in Eiffel as class <eiffel>DATA_CONSTRAINT</eiffel>.
You'll see a little more about namespaces, assemblies, and Eiffel clusters in [[Type Organization|Type Organization]] .
===Similar Types from Both Libraries===
You may have noticed a similarity in the names and descriptions from the Eiffel Base Library and those from the .NET "mscorlib" library. This is not by accident. The Eiffel class <code>STRING</code> is a different class from the .NET type <code>System.String</code>, which Eiffel programmers see represented as Eiffel class <code>SYSTEM_STRING</code>. There is more on this subject in [[Similar Types Occurring in Both Libraries|Similar Types Occurring in Both Libraries]] .
==Eiffel Feature Names==
By convention, feature names in Eiffel use all lower case characters, and like class names, words are separated by underscore. Also as with class names, the names of members from .NET assemblies will be represented in a form that complies with the Eiffel convention.
Let's look at some simple examples. First some feature names from the Eiffel Base Library.
<code>
to_upper
From class STRING: Converts to upper case.
item_double
From class RANDOM: The current random number as a double between 0 and 1
</code>
Now check out these member names from the .NET "mscorlib" type library. These have been made available to Eiffel for .NET programmers in the Eiffel convention. Following the Eiffel name, you see their .NET member name and type name.
<code>
to_upper
Member ToUpper from typeSystem.String
Returns a new System.String with the same content as the target, except all upper case.
next_double
Member NextDouble from type System.Random
A double-precision floating point number greater than or equal to 0.0, and less than 1.0.
</code>
So, Eiffel feature names, and the names of .NET members made available to Eiffel for .NET programmers, are all lower case with words separated by underscores.
==Overloaded .NET Member Names==
The .NET object model allows overloading of function names. This means that a .NET type can support multiple functions with the same name, that vary only by the types of the arguments they accept. For example, the .NET type System. Text. StringBuilder supports nineteen overloaded versions of the Append function. Here are a couple of examples, in their .NET forms:
<code>
.NET function signature: Append(System.String)
Member of type System.Text.StringBuilder
Appends a copy of the specified string to the end of this instance.
.NET function signature: Append(System.Char)
Member of type System.Text.StringBuilder
Appends the string representation of a specified Unicode character to the end of this instance.
</code>
The Eiffel programming language does not allow overloading routine names. That means that you cannot code multiple routines with the same name in a single class. That in itself is not a problem. But it also means that to work in the .NET environment, where overloading is allowed some compromise has to be made. So, what happens is this: if you are programming in Eiffel for .NET and you are using types from a .NET assembly, those types will be presented to you as if they are Eiffel classes. We have already seen that the type and feature names will be shown in the Eiffel naming convention. With overloaded feature names, the presentation will use name augmentation to disambiguate the overloaded versions. What you see is a distinct feature name for each overloaded version. The basic feature name is augmented by adding the types of its respective arguments, separated by underscore.
Let's look again at the two <code>Append</code> functions from <code>System.Text.StringBuilder</code>.
<code>
.NET function signature: Append(System.String)
Known to Eiffel as: append_string (value: SYSTEM_STRING)
Member of type System.Text.StringBuilder, known to Eiffel as STRING_BUILDER
Appends a copy of the specified string to the end of this instance.
.NET function signature: Append(System.Char)
Known to Eiffel as: append_character (value: CHARACTER)
Member of type System.Text.StringBuilder, known to Eiffel as STRING_BUILDER
Appends the string representation of a specified Unicode character to the end of this instance.
</code>
The overloading story does not end quite yet. The .NET object model allows the overloading of constructors. This issue will be discussed in the section Constructors and Creation Procedures.
==.NET Properties as Eiffel Features==
Properties in .NET provide:
* the opportunity to '''strengthen encapsulation,''' because values cannot be receive assignment without executing the property's "set" code
* '''uniform access ''' queries because properties are queries, but unlike previous C-style OO languages in which properties did not exist, if a property is used in programming a client class, the programmer does not need to know whether the data provided by the property was done so from memory or through computation. This leaves the producer of the class with the property the latitude to change the implementation without breaking existing clients.
In Eiffel, the same goals are fulfilled, but a little differently. Simple attributes are well-encapsulated, because the Eiffel programming language does not allow direct assignment to them from outside the control of their class. So any assignment of the form <code>x</code>. <code>f</code> := <code>y</code> is not valid in Eiffel. To allow client to set values of the attribute <code>f</code>, the producer of the class of which <code>x</code> is an instance would have built a command (a "<code>set_</code>" procedure) to do so. Then the code in a client to set <code>f</code> would look like this: <code>x</code>.<code>set_f</code> (<code>y</code>).
Uniform access is achieved in Eiffel through the way in which clientssee features which are queries. The code " <code>print</code> ( <code>x</code>.<code>count</code>)" applies the query <code>count</code> to the object attached to <code>x</code> and prints the result. You cannot tell by looking at this code whether <code>count</code> is an attribute or a function, that is, whether the <code>count</code> is returned from memory or through computation. In fact, it could be either, but that is a matter for its producer to deal with. As reuse consumers the implementation of <code>count</code>is not important to us ...but the fact that the producer can change the implementation without causing our code to need modification is very important to us.
Because Eiffel does not support properties directly, the propertiesof typeswhich Eiffel for .NET programmers usefrom .NET assemblies have to be mapped to Eiffel features.
In order to ask for the property's current value (technically, receiving the result of the property's <code>get</code> routine), a query feature is generated for the property. The query will be namedthe Eiffel name of the property.
As noted above, setting the value of a property cannot be done in Eiffel as it is done in C# and VB.NET because Eiffel disallows assignments of the form <code>x</code>.<code>f</code> := <code>y</code>. So, for each writable property, an Eiffel command feature is available to set the value of the property. The name for this command will be "<code>set_</code>" followed by the Eiffel name for the property.
As a result, the code for using a .NET property looks very much like the code to use an Eiffel attribute. In the following code fragment, an instance of the type <code>System.Windows.Forms.Form</code> which is available in Eiffel for .NET as <code>WINFORMS_FORM</code> is used by an Eiffel client. <code>System.Windows.Forms.Form</code> has a property <code>Text</code> which is of type <code>System.String</code>. Here the <code>Text</code> property is being set using the <code>set_text</code> feature, and then being recalled by using the query <code>text</code>.
<code>
local
my_window: WINFORMS_FORM
my_string: SYSTEM_STRING
do
create my_window.make
my_window.set_text (my_window_title) -- Set Text property
my_string := my_window.text -- Query Text property
.
.
end
</code>
==Static Features in .NET==
In the .NET object model it is possible for certain members of a type to be "static". When these members are used, they are used without an instance of the class as a target. In essence, they are called on the class itself.
In Eiffel for .NET, these staticmembers will made available with feature names derivedusing the same conventions as ordinary features, but applying them will be a bit different.
There is not a concept analogous to static members in Eiffel. The model for object-oriented computation in Eiffel specifies that whenever feature application takes place, there must be an object, i.e. an instance of some class, that serves as a target.
In order to use .NET types that include static members, a special syntax has been added into Eiffel for .NET. The following example uses this syntax to call a static function:
<code>
local
my_window: WINFORMS_FORM
do
create my_window.make
my_window.set_text (my_window_title)
.
.
{WINFORMS_APPLICATION}.run_form (my_window)
end
</code>
The type <code>System.Windows.Forms.Application</code> is used here. It is available to Eiffel under the name <code>WINFORMS_APPLICATION</code>. The static member being used is <code>Run</code>, in particular the overloaded version of <code>Run</code> which takes an argument of type <code>System.Windows.Forms.Form</code>. That version is available in Eiffel under the name <code>run_form</code>.
The important thing to see here is that when you need to apply a static member, you introduce the call with the keyword <code>feature</code>. Then enclose the type name in braces and apply the feature as if it were targeted to an object. This isfairly close to the way that the call would be made in C#, where the feature name would be applied to the type name, versus a target object:
<code>
{
Form my_window;
my_window = new Form();
my_window.Text = "Hello World!";
.
.
Application.Run(my_window); // This is C#
}
</code>

172
documentation/trunk/solutions/dotnet/eiffel-net-language/conventions/eiffel-net-terminology.wiki Normal file
View File

@@ -0,0 +1,172 @@
[[Property:title|Eiffel for .NET Terminology]]
[[Property:weight|1]]
[[Property:uuid|ab1ac480-e2d3-df5d-5f06-963899f1072d]]
==Eiffel Terminology Defined for C# and VB.NET Programmers==
Eiffel programmers feel that it is important to have a set of precise terms with which to communicate about our method of software development. Like everything else in Eiffel, the use of certain terms is not accidental. They were chosen carefully to impart particular meaning. Many of the Terms that Eiffel programmers use are different from those used by developers using other object-oriented languages. But that does not mean that their meanings will be foreign to you. If you have some understanding of object-oriented technology, you will find that in many cases the Eiffel terms describe concepts with which you were already familiar, just under different names, and possibly with slightly different meanings.
The intention of this glossary is to give you a list of these terms with extended definitions that will relate the Eiffel terms to language with which you may be more familiar. Also, you will find an occasional term which comes from other programming cultures but is not used in Eiffel.
{|
|-
| Term
| Definition
|-
| Ancestors
| The set of Classes from which a particular Class Inherits, including the Class itself. Somewhat analogous to Bases and Interfaces in C# and VB.NET (see Proper Ancestors).
|-
| Argument
| An object which is passed to a routine. Called a Parameter in C# and VB.NET.
|-
| Assertion
| A declaritive expression that evaluates to true or false. Assertions in Eiffel are of different types and are used primarily for expressing software specification to potential Reuse Consumers and ensuring that executing software complies with specification. Any violation of an assertion causes an exception, and is generally indicative of a defect in the software system.
|-
| Attribute
| A Feature which represents storage used in every instance of a class. Used like a Field member in C#.
|-
| Class
| Software text which is the static definition of a Type (or the pattern for a Type in the case of a Generic Class). Used in very nearly the same way as in C#. In C# Classes are used for reference types and Structures for value types. In Eiffel, Classes are used for both, but see Expanded Class.
|-
| Class invariant
| An Assertion on a Class which defines the valid or stable state for objects which are instances of the Class. All instances of the Class must comply with the Class Invariant at any time that they are accessible to Clients.
|-
| Client
| A Class whose role is that of Client in a Client/Supplier Relationship with another Class.
|-
| Client/Supplier relationship
| One of the two Relationships that can exist between Classes. Client/Supplier is characterized by a situation in which one Class, called the Client, has or uses, instances of the other Class, called the Supplier. For example, if class "X" declares an entity "y" of type STRING, then Class X becomes a Client to Class STRING as a result. At the same time, Class STRING becomes a Supplier to class X.
|-
| Cluster
| A group of classes (or recursively, clusters) which share some criteria which justifies their being grouped together. Classes are usually clustered together because they model similar entities or have similar functionality. For example, in the Eiffel Base Library, there is a cluster called "structures" which contains clusters for data structures. One cluster is "list" which contains classes like LINKED_LIST and TWO_WAY_LIST. Another "structures" cluster is "dispensers" which contains classes like "ARRAYED_STACK" and "PRIORITY_QUEUE". When .NET assemblies are made available to Eiffel programmers, each assembly is viewed as a cluster.
|-
| Command
| A Class Feature which can change the state of the instance to which it is applied, and does not return a result. It is the Reuse Consumer's view of a Procedure.
|-
| Contract
| Like a contract between human parties, a software Contract is a formal agreement between software components, Classes in the case of Eiffel. The contract is written in the Assertions of a Supplier Class and specifies in precise terms those conditions with which potential Clients may interact with the Supplier. The contract for a particular Class is composed of the contracts for each Exported Routine of the Class as well as the Class Invariant.
|-
| Creation Procedure
| A Procedure which can be used to initialize and instance of a Class. Similar to a Constructor in C# or VB.NET, but slightly different. A Creation Procedure can be applied when an object is being created, but can also be applied later to reinitialize an existing object (such is not the case with Constructors). Also, Creation Procedures are responsible for ensuring that newly created objects comply with their Class Invariants.
|-
| Deferred Class
| A class which has at least one Deferred Feature. The term "Deferred" is used in the Eiffel culture like the term "Abstract" in .NET. Like an abstract class in C# or VB.NET, it is not possible to make direct runtime instances of a Deferred Class.
|-
| Deferred feature
| A Class Feature which has not implementation. Like a virtual method in C#. Can apply to Commands or Queries.
|-
| Descendents
| The set of all Classes which Inherit from a particular Class, including the Class itself. Somewhat analogous to subclasses in C# and VB.NET (see Proper Descendants).
|-
| Design by contract
| A method of developing software in which a System is composed of a set of interacting Classes which cooperate based upon precisely defined Contracts.
|-
| Direct instance
| A runtime Object of some type, based directly on the definition from a specific Effective Class. See Instance for more information. Usually used in conjunction with the class name, e.g. "an instance of class POLYGON".
|-
| Effective class
| A Class which has no Deferred Features. Only if a Class is Effective can it have direct runtime instances. Effective classes are called Concrete Classes in some programming cultures.
|-
| Eiffel Metadata Consumer
| Applicable to Eiffel for .NET only, this is a mechanism that works behind the scenes to make Types from .NET assemblies available to Eiffel programmers. The Metadata Consumer reconciles the differences between the naming conventions of Eiffel and .NET by providing an Eiffel compliant view of the Types in .NET assemblies.
|-
| Expanded Class
| Like a value type in C#, but with some restrictions. .NET value types are viewed to Eiffel programmers as Expanded Classes. For reference types, an object field holds a reference to a runtime object (or is Void). For value types, the object field holds the fields of the runtime object. A Type based on an Expanded Class is an Expanded Type.
|-
| Exported feature
| A Feature which is available to Client Classes. Analogous to "public" in C# and VB.NET. However, Exporting in Eiffel has fine granularity. It is possible to make certain Features available to Clients of all types or only to Clients which conform to certain named Classes (vs Public, Protected, Private)
|-
| Feature
| Any of a Class's Attributes or Routines. Used similarly to the term Member as in C#. In Eiffel class features can be only Attributes or Routines.
|-
| Feature Application
| The process of using the Class Features on instances of the Class. The model for Feature Application is "x.f(a,...)" where "x" is an entity which will be attached to some object at runtime, "f" is some Feature of the Class on which x is based, and "a,..." is an optional list of arguments which may be appropriate for some Routines. Feature "f" is "applied" to the object attached to "x". Feature Application may involve calling Routines, or may only involve returning the value of an Attribute from memory. Feature application is sometimes called "feature call".
|-
| Function
| A Routine that returns a result. In C# function results can be typed as "void", meaning that there is no result returned. Eiffel functions cannot be typed "void" (see Procedure). All Functions must specify a result type. Of course, if the result type is a reference type, there could be cases in which the reference resulting from some specific call might be Void.
|-
| Generic Class
| A Class which is written using parameters to represent other Classes or Types to enhance its reusability. For example, the Class LINKED_LIST [G] is a generic class in which "G" represents some other Class. So, LINKED_LIST is written independent of the items an instance of the list will hold. We cannot declare a LINKED_LIST without specifiying a Class to substitute for "G". If we want a list of cats we can declare one by using the Type: LINKED_LIST [CAT]. Generic Classes are not currently implemented in .NET, so there's no corresponding concept in C#.
|-
| Inheritance
| One of the two Relationships that can exist between Classes. If Class B inherits from Class A, then every feature in Class A is potentially available to instances of Class B. Also, when ever an instance of Class A is required, an instance of Class B will suffice. Inheritance is used in Eiffel much the same as in C#. The Eiffel model allows full, controlled multiple inheritance, though. Eiffel Classes may inherit from multiple Concrete Classes and name clashes are handled through a process called Feature Adaptation.
|-
| Heir
| The adjacent Proper Descendants of a Class. If class C inherits from class B and class B inherits from class A, then class A's Proper Descendants include B and C, but A's Heirs only include B.
|-
| Instance
| A runtime Object of some type, based on the definition from a Class. Usually used in conjunction with the class name, e.g. "an instance of class POLYGON". In contrast with Direct Instance, an Instance of class POLYGON is a Direct Instance of POLYGON or any Proper Descendant of POLYGON such, perhaps, as RECTANGLE. So it its possible to have Objects which are Instances of Deferred Classes, but it is impossible to have Objects which are Direct Instances of Deferred Classes.
|-
| Interface
| Not supported as such in Eiffel. Used in C# and VB.NET, Interfaces provide sets of specific Class Features which must be effected by any Concrete Class that "implements" the Interface. There is no concept of Interface in Eiffel that is separate from the concept of Class. So, Interfaces from .NET appear to Eiffel programmers to be completely Deferred (abstract) Classes.
|-
| Manifest string
| A quoted string used in source code, for example the "Hello World!" in: <br/>
my_string := "Hello World!" <br/>
This is often called a "literal" string in other languages. In Eiffel, the quoted string "Hello World!" above is, by virtue of its presence, an instance of the Eiffel STRING class. In Eiffel there are manifest constants of other types as well, like numbers coded explicitly in software text, and the keywords True and False as the manifest booleans.
|-
| Module
| A syntactical grouping of software text. Source code is divided into Modules in order to help organize it in some meaningful way or to achieve some goal.
|-
| Object
| An instance of a Class during system execution. As such, Objects only exist at runtime.
|-
| Overloading
| Not supported in Eiffel. Overloading is the ability to have more than one Feature with the same name, varying only by the Types of its Arguments. Overloading is supported by the underlying object model in .NET. As a result many classes in .NET assemblies have overloaded methods. The Eiffel Metadata Consumer disambiguates the overloaded names so that by the time you see them in the Eiffel context they appear no longer to be overloaded.
|-
| Parent
| The adjacent Proper Ancestors of a Class. If class C inherits from class B and class B inherits from class A, then class C's Proper Ancestors include A and B, but C's Parents only include B.
|-
| Postcondition
| An assertion coded on a Routine which defines the conditions will be true upon successful completion of the Routine. It is the responsibility of the Routine to ensure that the Postcondition holds after the Routine executes.
|-
| Precondition
| An assertion coded on a Routine which defines the conditions under which the Routine can complete successfully. It is the responsibility of the Client to ensure that the Precondition holds before attempting to call the Routine.
|-
| Procedure
| A Routine that does not return a result. Much like a "void" function in C#.
|-
| Proper ancestors
| The set of all Classes from which a particular Class Inherits, excluding the Class itself.
|-
| Proper descendents
| The set of all Classes which Inherit from a particular Class, excluding the Class itself.
|-
| Query
| A Class Feature which returns information from the instance to which it is applied. Queries are the Reuse Consumer's view of Attributes and Functions.
|-
| Reference type
| A type whose instances are accessed via a reference. For reference types, an object field holds a reference to a runtime object (or is Void). This is in contrast to value types, in which case, the object field holds the fields of the runtime object. In Eiffel, reference types are based on reference classes, i.e., any class which is not an Expanded Class.
|-
| Relationship
| An association between two classes. There are only two types of Relationships that can exist between classes: Client/Supplier and Inheritance.
|-
| Reuse consumer
| The role a software engineer assumes when in the process of making use of Classes or Types already in existence. As a reuse consumer, the engineer is interested primarily in the specification of those Classes or Types being used, rather than their implementation.
|-
| Reuse producer
| The role a software engineer assumes when in the process or creating a new Class. In this role the engineer attempts to produce a product which will be reusable by him or herself and other engineers in the future. In the Eiffel culture, whenever a software engineer creates a class, it is as a Reuse Producer, and with the thought that each new class has the potential to become reusable.
|-
| Root class
| For any System, the Class which will be instantiated to start the system. Specified by project settings.
|-
| Root procedure
| A Creation Procedure of the Root Class of a System which will be applied to an initial instance of the Root Class at System startup. Similar to Main() in C# and VB.NET, but with the important difference that the fact that a particular Creation Procedure is the Root Procedure for a System is not define in the Class itself as with Main(). Rather, it is specified outside the Class in project settings. This helps Reuse Producers keep Classes more autonomous and therefore potentially more reusable.
|-
| Routine
| A computational Class Feature which is either a Function or Procedure. Routines are the executable parts of a Class. Routines are similar to Methods in C#.
|-
| Software specification
| A statement of how a software element is to be used and what it will do when executed. Ideally, this is stated in terms that do not betray how the software does what it does.In Eiffel, specification is included in the code, rather than a separate document. For a routine, it consists of its call signature and its contract. For a class, it consists of the signatures and contracts for all public features.
|-
| Supplier
| A Class whose role is that of Supplier in a Client/Supplier Relationship with another Class.
|-
| System
| A set of Classes related by the two Relationships which can be compiled to produce an executable.
|-
| Type
| The description of a set of Objects equipped with certain Features.
|}

9
documentation/trunk/solutions/dotnet/eiffel-net-language/conventions/eiffel-reserved-words.wiki Normal file
View File

@@ -0,0 +1,9 @@
[[Property:title|Eiffel reserved words]]
[[Property:weight|6]]
[[Property:uuid|3b80ea3e-2ed1-adf6-ddf5-acd4e18c6d03]]
The Eiffel programming language reserves certain words as meaningful to the Eiffel compiler.
To learn more about the reserved words specified by the current Eiffel standard, see the [[Eiffel programming language reserved words]] page of the [[Quick reference to the Eiffel programming language]].

15
documentation/trunk/solutions/dotnet/eiffel-net-language/conventions/index.wiki Normal file
View File

@@ -0,0 +1,15 @@
[[Property:title|Conventions]]
[[Property:weight|1]]
[[Property:uuid|1f101597-06cd-b851-8cc1-e214b3eedb3e]]
In this section, you'll find information about how the conventions that are normally used in Eiffel programming are affected by working in the presence of .NET.
Also, you'll find out how .NET types sometimes look a little different in the presence of Eiffel.
Because there are differences in the underlying object models upon which .NET and Eiffel have been designed, before .NET types can be made available to Eiffel developers, the assemblies in which they reside must be processed by a utility called the Eiffel Metadata Consumer. Fortunately, this all happens behind the scenes for you. You need only be aware that when you are looking at .NET types from within EiffelEnvision, you're seeing them through Eiffel-tinted lenses.
This is really the same thing that happens with other .NET languages with Visual Studio .NET support. For example, if you look at a constructor in a .NET type using the "ildasm" utility, the constructor will be named "<code>.ctor</code>". But, if you're in C# and look at the same constructor in the Visual Studio .NET Object Browser, the constructor will have the same name as the type ...it's a C# convention. Likewise, the same constructor viewed in Visual Basic .NET will have the name <code>New</code> ...that's the Visual Basic .NET convention. So, when you use EiffelEnvision, you see things as presented using Eiffel Conventions.
Consider what happens when you look at .NET types using EiffelEnvision. When you look, for example at the type <code lang="text">System.EventArgs</code>, you will see it represented as an Eiffel class called <code>EVENT_ARGS</code>. The members of the .NET type will show up as features of the Eiffel class. Of course, you can also see the corresponding .NET names as they exist in the assembly metadata.
The documents in this section tell you what you need to know in order to use .NET types in Eiffel, and vice versa.

77
documentation/trunk/solutions/dotnet/eiffel-net-language/conventions/similar-types-occurring-both-libraries.wiki Normal file
View File

@@ -0,0 +1,77 @@
[[Property:title|Similar Types Occurring in Both Libraries]]
[[Property:weight|5]]
[[Property:uuid|4c9f6ad8-107b-af69-3eb3-3f076f2c936c]]
==Whose String is it anyway?==
Over the last 15 years or so, the Eiffel class libraries have been a source for reusable software components for developers.
The Eiffel Base library contains classes for commonly used objects like different kinds of numbers, strings, files, and data structures.
But there are also libaries of Eiffel classes for sophisticated purposes like lexical analysis and parsing, data access, and graphical user interface development.
Likewise .NET is delivered with assemblies containing thousands of powerful types with similar purposes.
===Working in Both Worlds===
When we build software that has access to both the rich Eiffel libraries and the many useful .NET types, we inevitably run into types from both worlds that have similar names and purposes, but are still different types with different semantics.
===The Case of Strings===
The example of these similar types which will almost certainly get in your face is the string types. You may remember that we looked briefly at the case of the string types in Naming Conventions and Name Handling.
The Eiffel Base Library contains class <code>STRING</code>; the .NET assembly contains type <code>System.String</code>, which Eiffel for .NETusers see as <code>SYSTEM_STRING</code>. At an abstract level both of these model sequences of characters. But they are not the same type. In fact, they are different in some important ways. For example, instances of <code>System.String</code> are immutable. So you cannot append to an instance of <code>System.String</code>. If you want to build a string by appending, you should use an instance of <code>System.Text.StringBuilder</code> to do the appending, then extract the instance of <code>System.String</code> from it. With <code>STRING</code> it is permissible to append, so you don't need a helper like the <code>System.Text.StringBuilder</code> type.
So the two types are similar at an abstract level, but different semantically. There are reasonable arguments for the design of each.
Many types in the delivered assemblies have properties which are strings or methods which return or take strings as arguments. In all these cases, the strings in question are instances of <code>System.String</code>.
Many classes in the delivered Eiffel libraries have features involving strings, that is attributes which are strings or routines which return or take strings as arguments. In all these cases, the strings are instances of <code>STRING</code> (except for those designed for .NET compliance).
In C# and VB.NET, if you specify a quoted string like <code>"Hello World!"</code> in your code, that string will conform to type <code>System.String</code>. If you do the same in Eiffel, then <code>"Hello World!"</code> will be an instance of <code>STRING</code>. In Eiffel terminology, <code>"Hello World!"</code> appearing in source code is a manifest string.
What all this means to you is that you cannot use an instance of <code>System.String</code> when an instance of <code>STRING</code> is called for, and vice versa. Three out of four of the executable lines in the following code sample are invalid:
<code>
local
my_string: STRING
my_system_string: SYSTEM_STRING
do
my_system_string := "Hello World!" -- Invalid
my_string := "Hello World!" -- Valid
my_string := my_system_string -- Invalid
my_system_string := my_string -- Invalid
.
.
end
</code>
To handle this issue, the Eiffel for .NET class <code>STRING</code> has two features which can be used when a string of the other type is needed.
The first of these features is a query <code>to_cil</code> which returns an object of type <code>System.String</code> which has a sequence of characters equivalent to that of the <code>STRING</code> to which <code>to_cil</code> is applied. The <code>to_cil</code> can be applied to manifest strings by enclosing the manifest string in parentheses.
The other feature is a creation procedure named <code>make_from_cil</code> which takes as an argument an instance of <code>System.String</code> and initializes its target <code>STRING</code> with a sequence of characters equivalent to that of the argument.
In the following sample, we use these features of <code>STRING</code> to make all the lines from the previous sample valid.
<code>
local
my_string: STRING
my_system_string: SYSTEM_STRING
do
my_system_string := ("Hello World!").to_cil -- Valid
my_string := "Hello World!" -- Valid
my_string.make_from_cil (my_system_string) -- Valid
my_system_string := my_string.to_cil -- Valid
.
.
end
</code>
{{note|As shown in the above example, it is necessary to apply <code>to_cil</code> to a manifest string if you are assigning it to a <code>System.String</code> or passing it as an argument where a <code>System.String</code> is called for. <br/>
This is expected to change in a future release. It shall become unnecesary to apply <code>to_cil</code> to manifest strings. Instead, whether a <code>STRING</code> or <code>System.String</code> is needed will be determined by the context in which the manifest string is being used, and the proper type of object will be generated. }}
===Other Similar Types===
There are many other cases of types available from the .NET assemblies which have similar purpose and semantics to those found in the Eiffel libraries. Fortunately, there is none that you will have to deal with as often as strings.

56
documentation/trunk/solutions/dotnet/eiffel-net-language/conventions/type-organization.wiki Normal file
View File

@@ -0,0 +1,56 @@
[[Property:title|Type Organization]]
[[Property:weight|3]]
[[Property:uuid|1837e091-695b-339c-f04f-cbfaea791a6c]]
In any comprehensive object-oriented system, the act of programming results in creation of new data types. There must be a way of organizing these types and/or their static representation as classes. This section tells you how classes are organized in Eiffel and in .NET, and how these organization methods are used together.
==Eiffel Clusters==
Eiffel classes are grouped in clusters. These clusters of classes ordinarily share some commonality of functionality or purpose. In other words,the classes in a particular cluster may provide the same sorts of capabilities or relate to a single software model. In the Eiffel Base Library there is a cluster called <code>list</code> which contains classes which implement different types of lists, for example, <code>ARRAYED_LIST</code>, <code>LINKED_LIST</code>, <code>SORTED_TWO_WAY_LIST</code>, <code>TWO_WAY_CIRCULAR</code>. At an abstract level all these classes are related to the software model of the notion of "list".
The cluster <code>list</code> is actually a subcluster of the cluster <code>structures</code> which contains clusters other than <code>list</code> related to data structures other than lists. Eiffel convention dictates that a cluster should either contain classes or subclusters, but not both.
So clusters serve both to categorize and locate classes. So, class <code>LINKED_LIST</code> can be described as a basic library class implementing a data structure, more particularly a list. As such, it can be found in the Base Library, in cluster <code>structures</code> in subcluster <code>list</code>.
==.NET Namespaces and Assemblies==
In .NET, types (the language independent, compiled form of classes) are stored in "assemblies". So, we locate a type we want to use by referencing the assembly in which it resides.
As .NET programmers, we think of types as being categorized by namespace. For example, we view the type <code>System.Windows.Forms.TextBox</code> as the <code>TextBox</code> type in the context of the windows forms namespace ( <code>System.Windows.Forms</code>). Particularly, this is in contrast to type <code>System.Web.UI.TextBox</code> which is a <code>TextBox</code> for web forms. As it relates to making .NET types usable by Eiffel, the important thing to understand is that the real .NET type name is the fully qualified type name, including the namespace. Namespaces are simply a bit of "syntactic sugar" that keeps us from having to repeat the entire type name every time we use it in source code.
===.NET Assemblies Available to Eiffel===
When types from .NET assemblies are made available to Eiffel programmers, each assembly is mapped to a cluster. So all the types in an assembly appear as if they were Eiffel classes in a cluster which corresponds to the .NET assembly.
To summarize, as you learned in Naming Conventions and Name Handling, unambiguous Eiffel-style names are made available for the.NET types in an assembly. The assembly is represented to Eiffel for .NET programmers as a cluster of classes. The process of name derivation is based upon a portion of the .NET type name, possibly augmented with a prefix to ensure uniqueness.
===Assemblies Built with Eiffel===
The object model for which Eiffel was designed differs in some ways from the .NET object model. Importantly, Eiffel supports the facilties of full, controllable multiple inheritance, and genericity, among other things, that the inherent .NET object model does not. That does not mean that these things cannot work in .NET. Indeed they can, and they make Eiffel for .NET very powerful. But, they do make things look a little different.
When you compile Eiffel for .NET, the result is a .NET assembly; either an executable system, or a library of potentially reusable data types. Because the object model for Eiffel is different from that of .NET, the assembly resulting from a compile is different in some ways.
First an assembly built using Eiffel for .NET will likely contain lots of types and interfaces. This is because as you use a class from the Eiffel libraries, say class <code>STRING</code>, all the classes upon which <code>STRING</code> depends ( <code>STRING</code>'s suppliers and ancestors) must also be included in the assembly. That's because the Eiffel libraries, unlike the Microsoft .NET libraries like <code>mscorlib</code> and <code>System.Data</code>, are not distributed as shared type libraries.
Another thing you may notice is that each Eiffel class you produce is represented by three entities in the assembly ... two classes and an interface. So, if you produce a class called <code>GUARD_DOG</code>, then in the assembly you'd see an interface called <code>GuardDog</code>, a class called <code>Impl.GuardDog</code>, and a class called <code>Create.GuardDog</code>. Again, this is done for reasons that concern the differences in the object models between Eiffel and .NET.
The <code>GuardDog</code> interface is what you use when you declare an entity or variable of that type. The objects attached to that entity at runtime will be of the type <code>Impl.GuardDog</code>. You create an instance of <code>Impl.GuardDog</code> and attach it to an entity of type <code>GuardDog</code> by calling a routine in the factory class <code>Create.GuardDog</code>. The factory routines will almost always have names that begin with the word " <code>Make</code>", and represent the creation routines of Eiffel the classes. So in the case of using an instance of <code>GuardDog</code> from a C# class, the code would like this:
<code>
{
GuardDog aGuardDog = Create.GuardDog.Make(); //Create an instance
aGuardDog.RollOver(); // Apply a feature
}
</code>
This object creation model accounts for some of the differences between constructors in .NET and creation procedures in Eiffel. These differences will be discussed in more detail in Constructors and Creation Procedures.
Another advantage is that it provides a syntax that is similar to that used to create objects in Eiffel. An Eiffel for .NET client to the class <code>GUARD_DOG</code> might use the following code to create and use an instance.
<code>
local
a_guard_dog: GUARD_DOG -- Declare an entity of the type
do
create a_guard_dog.make -- Create an instance and attach to entity
a_guard_dog.roll_over -- Apply a feature
end
</code>
You may have noticed in these examples that even though the type <code>GuardDog</code> was compiled from an Eiffel class, when the C# client uses <code>GuardDog</code>, it uses what would be considered the .NET naming convention for the type <code>GuardDog</code> (vs. <code>GUARD_DOG</code>) and the method name <code>RollOver</code> (vs <code>roll_over</code>). What happens here is that when assemblies are produced from Eiffel classes, by default .NET naming standards are used in the assembly.