mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2026-04-06 01:59:25 +02:00
Author:admin
Date:2008-09-30T16:23:49.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@65 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
jfiat
@@ -1,5 +1,6 @@
|
||||
[[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==
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
[[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 EiffelEnvision, 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.
|
||||
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==
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[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.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
[[Property:title|Eiffel Reserved Keywords]]
|
||||
[[Property:link_title|Eiffel reserved words]]
|
||||
[[Property:weight|6]]
|
||||
[[Property:uuid|3b80ea3e-2ed1-adf6-ddf5-acd4e18c6d03]]
|
||||
There are 56 language keywords in Eiffel which cannot be used as developer defined identifiers in Eiffel class code.
|
||||
|
||||
==Eiffel Reserved Keywords==
|
||||
|
||||
@@ -1,5 +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 ENViSioN, you see things as presented using Eiffel Conventions.
|
||||
|
||||
Consider what happens when you look at .NET types using ENViSioN. When you look, for example at the type <code> 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.
|
||||
|
||||
|
||||
@@ -65,7 +65,7 @@ In the following sample, we use these features of <code> STRING </code> to make
|
||||
end
|
||||
</code>
|
||||
|
||||
{{note| '''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/>
|
||||
{{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===
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[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==
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
[[Property:title|Eiffel for .NET Limitations]]
|
||||
[[Property:link_title|Eiffel for .NET Integration]]
|
||||
[[Property:weight|3]]
|
||||
[[Property:uuid|fe8a6a7d-4590-0db2-d59a-307082b18ecc]]
|
||||
==Differences between Eiffel and Eiffel for .NET==
|
||||
|
||||
===Limitation of Eiffel for .NET in version 5. 5===
|
||||
|
||||
@@ -201,7 +201,7 @@ In this feature:
|
||||
* "INTEGER" (after the argument list) is the feature's type.
|
||||
* "do " introduces the implementation code.
|
||||
* "Result := an_attribute + an_int" is an instruction.
|
||||
{{warning| '''Note:'''This feature is a function. As a consequence the computation uses the keyword "Result" as an entity name for the value to be returned by the function }}
|
||||
{{note|This feature is a function. As a consequence the computation uses the keyword "Result" as an entity name for the value to be returned by the function }}
|
||||
|
||||
* "end" ends the feature declaration
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[Property:title|Design by Contract and Assertions]]
|
||||
[[Property:weight|5]]
|
||||
[[Property:uuid|41172f82-227a-96b1-2dad-624f04374ee0]]
|
||||
==Motivation: Concerning Correctness==
|
||||
|
||||
When you produce an element of software, how do you know that what you produced is correct?
|
||||
|
||||
@@ -26,7 +26,7 @@ class
|
||||
end
|
||||
</code>
|
||||
|
||||
Okay, so class SIMPLE is only interesting in its simplicity. Let's look at a more useful example:
|
||||
Okay, so class SIMPLE is only interesting in its simplicity. Let's look at an example that is more illustrative:
|
||||
<code>
|
||||
indexing
|
||||
description: Objects that model lists
|
||||
@@ -72,7 +72,7 @@ invariant
|
||||
before_constraint: before implies (active = first_element)
|
||||
after_constraint: after implies (active = last_element)
|
||||
</code>
|
||||
Here is a class that, although somewhat contrived, utilizes all of the required and optional parts of the class. Let's look at each part individually.
|
||||
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===
|
||||
<code>
|
||||
indexing
|
||||
|
||||
@@ -1,9 +1,10 @@
|
||||
[[Property:title|Eiffel for .NET Compliance]]
|
||||
[[Property:weight|9]]
|
||||
[[Property:uuid|1e19c2f0-995e-02c1-0588-c134a11e0003]]
|
||||
As of EiffelEnvision 2.6, Eiffel for ASP.NET 5.6 and EiffelStudio 5.7; Eiffel for .NET introduces the notion of '''Eiffel-Compliance'''. .NET specifies a number of language interopability rules in a [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp Common Language Specification-Compliance] specification. Eiffel for .NET supports all CLS-Compliant type and features in .NET but now additionally supports a number of non-CLS-compliant types and features. This is the purpose of the Eiffel-Compliant notion.
|
||||
As of Eiffel for ASP.NET 5.6 and EiffelStudio 5.7; Eiffel for .NET introduces the notion of '''Eiffel-Compliance'''. .NET specifies a number of language interoperability rules in a [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp Common Language Specification-Compliance] specification. Eiffel for .NET supports all CLS-Compliant type and features in .NET but now additionally supports a number of non-CLS-compliant types and features. This is the purpose of the Eiffel-Compliant notion.
|
||||
|
||||
The information contained within this page does not go into any depth on the Common Language Specification (CLS) or CLS-Compliance. For this information please see Microsoft's on-line documentation [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp What is the Common Language Specification?]
|
||||
|
||||
{{note|The information contained within this page does not go into any depth on the Common Language Specification (CLS) or CLS-Compliance. For this information please see Microsoft's on-line documentation [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp What is the Common Language Specification?] }}
|
||||
<span id="applicablity"></span>
|
||||
==Applicability==
|
||||
|
||||
@@ -11,7 +12,7 @@ The CLS states a number of rules .NET tools have to abide by to be CLS-compliant
|
||||
<span id="what_is_compliant"></span>
|
||||
==What is Eiffel-Compliant?==
|
||||
|
||||
As already state, anything CLS-compliant is Eiffel-compliant. Eiffel-Compliancy merely allows for exceptions so that non-CLS-compliant assemblies, types and members can be used in Eiffel for .NET.
|
||||
As already stated, anything CLS-compliant is Eiffel-compliant. Eiffel-Compliancy merely allows for exceptions so that non-CLS-compliant assemblies, types and members can be used in Eiffel for .NET.
|
||||
|
||||
The following list outlines the supported non-CLS-compliant types:
|
||||
* All unsigned numerical basic types such as <eiffel>System.UInt32</eiffel> as <eiffel>System.UInt64</eiffel>, represented by <eiffel>NATURAL_xx</eiffel>.
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[Property:title|Event Programming with Agents]]
|
||||
[[Property:weight|7]]
|
||||
[[Property:uuid|ea9d7b9d-daa1-a415-628a-e3a2f935c12a]]
|
||||
In Eiffel there is a facility referred to as agents.
|
||||
|
||||
The implementation of agents is an advanced topic, but you do not have to understand the details of the implementation of agents to put agents to work for you. That is what you will learn in this section.
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[Property:title|Exception Mechanism]]
|
||||
[[Property:weight|6]]
|
||||
[[Property:uuid|84a159dd-4a19-af73-7b0b-0618a284142a]]
|
||||
==Motivation: Concerning Robustness==
|
||||
|
||||
The notion of software correctness that we saw in [[Design by Contract and Assertions|Design by Contract and Assertions]] is half of the formula for software reliability. Correctness covers what the software is supposed to do, that is, its specification.
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[Property:title|Genericity]]
|
||||
[[Property:weight|4]]
|
||||
[[Property:uuid|3a0bfe10-78e7-00eb-d9a0-b977d1fa352a]]
|
||||
We got a very short introduction to generic classes when we were looking at the formal generic part of class structure in [[Eiffel Classes|Eiffel Classes]] . That discussion left to the imagination the motivation and benefits for creating generic classes.
|
||||
|
||||
You will see that most of the generic classes model containers for multiple items and at least one of their formal generic parameters represents the type of items that are to be stored in the container. Some generic classes, like <code> LINKABLE </code>, care for only one instance of the type represented by their formal generic parameter.
|
||||
|
||||
@@ -1,18 +1,19 @@
|
||||
[[Property:title|Eiffel for .NET]]
|
||||
[[Property:weight|2]]
|
||||
[[Property:uuid|446038d8-abd6-0a0d-2b90-94124e1ac810]]
|
||||
* [[Eiffel for.NET Language|Introduction]]
|
||||
* [[Eiffel Classes|Eiffel Classes]]
|
||||
* [[Adding Class Features|Adding Class Features]]
|
||||
* [[Inheritance|Inheritance]]
|
||||
* [[Genericity|Genericity]]
|
||||
* [[Design by Contract and Assertions|Design by Contract]]
|
||||
* [[Exception Mechanism|Exception Mechanism]]
|
||||
* [[Event Programming with Agents|Event Programming with Agents]]
|
||||
* [[Using Referenced Assemblies|Using Referenced Assemblies]]
|
||||
* [[Eiffel for .NET Compliance|Eiffel for .NET Compliance]]
|
||||
* [[Referenced Assembly Type and Feature Name Conversion|Referenced Assembly Type and Feature Name Conversion]]
|
||||
These pages contain documentation that describes the Eiffel programming language.
|
||||
|
||||
Eiffel is considered both a development methodology and a programming language.
|
||||
|
||||
Eiffel the methodology is a recipe for constructing quality software which is based on a small number of powerful concepts. Eiffel the programming language is a notation which is designed to support the methodology.
|
||||
|
||||
Eiffel for.NET is the Eiffel programming language made available in the .NET environment. Eiffel for.NET components can use and inherit from components in .NET assemblies that were produced using other.NET languages. And, programmers using other.NET languages can use and inherit from components in assemblies produced using Eiffel for.NET.
|
||||
|
||||
==Eiffel for.NET Conventions Documentation==
|
||||
|
||||
In Eiffel, as in other languages, certain conventions have evolved which constitute "the way things are done". Conventions provide consistency and therefore predictability and readability of software text.
|
||||
|
||||
When working in the.NET components, particularly when using components from .NET assemblies delivered from Microsoft or produced by other parties, the conventions of Eiffel are maintained in the view of these components. The first section, titled [[Conventions]], provides you with an understanding of Eiffel terminology, conventions , and how they work with .NET.
|
||||
|
||||
The remaining sections of this section are a reference for the Eiffel for .NET language. It is not a complete reference, though. Rather, it is intended to help you with the tasks that Eiffel programmers commonly encounter.
|
||||
|
||||
|
||||
@@ -192,7 +192,7 @@ The redefine part lists the names of effective features for which the producer o
|
||||
|
||||
So, in this example the implementation for <code> linear_representation </code>, for example, that <code> LINKED_QUEUE </code> would have inherited from <code> QUEUE </code> will not be used. Instead <code> LINKED_QUEUE </code> implements its own version of <code> linear_representation </code>.
|
||||
|
||||
{{note| '''Note:''' When a class implements a version of an inherited feature which was deferred in its parent, this is known as "effecting" the feature. Because features being effected are getting their first implementation, it is not necessary to list their names in the redefine part, or anywhere else in the inheritance part of the heir. }}
|
||||
{{note|When a class implements a version of an inherited feature which was deferred in its parent, this is known as "effecting" the feature. Because features being effected are getting their first implementation, it is not necessary to list their names in the redefine part, or anywhere else in the inheritance part of the heir. }}
|
||||
|
||||
===Select===
|
||||
<code>
|
||||
|
||||
@@ -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 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.
|
||||
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 match neither that of the OO Pascal variants nor 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?==
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
[[Property:title|Using Referenced Assemblies]]
|
||||
[[Property:weight|8]]
|
||||
[[Property:uuid|acbe0407-b95e-6268-fc20-238f91df595e]]
|
||||
Eiffel for.NET is a first class citizen in the Microsoft.NET programming world. This means that if you are programming in Eiffel for.NET, say with ENViSioN!, you have full access to the thousands of software components in the .NET type libraries. But, that's not all. You also have full access to the thousands of components in the traditional Eiffel class libraries. And even that's not all. You have the ability to build software components which comply with.NET standards, so that they can be used by programmers using any other .NET language. Still not all. When you use Eiffel, you can choose to build software that will run under Microsoft.NET, but will be portable to other popular operating systems as well.
|
||||
Eiffel for.NET is a first class citizen in the Microsoft.NET programming world. This means that if you are programming in Eiffel for.NET, you have full access to the thousands of software components in the .NET type libraries. But, that's not all. You also have full access to the thousands of components in the traditional Eiffel class libraries. And even that's not all. You have the ability to build software components which comply with.NET standards, so that they can be used by programmers using any other .NET language. Still not all. When you use Eiffel, you can choose to build software that will run under Microsoft.NET, but will be portable to other popular operating systems as well.
|
||||
|
||||
Being an Eiffel for.NET programmer obviously put you in a very powerful position. How do you take advantage of it?
|
||||
|
||||
|
||||
@@ -13,5 +13,3 @@ We will see:
|
||||
* what is Eiffel on .NET
|
||||
* which Eiffel mechanisms have been implemented and which haven't.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[Property:title|Known issues]]
|
||||
[[Property:weight|4]]
|
||||
[[Property:uuid|78c6b5c1-a87b-805d-38bd-fe64cb4e7c0d]]
|
||||
==Eiffel issues==
|
||||
* Check here first for the [[Eiffel for .NET Limitations|Difference between Eiffel and Eiffel for .NET]] .
|
||||
* The root creation routine of the root class must not take any arguments. You can access the command line given to the application via the class <code> ARGUMENTS. </code>
|
||||
|
||||
Reference in New Issue
Block a user