mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2026-04-05 09:39:31 +02:00
Author:admin
Date:2008-09-25T16:19:15.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@44 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
@@ -176,7 +176,7 @@ end -- Class SOME_CLASS
|
||||
|
||||
When you write a feature in a class, you typically will include some of the following:
|
||||
* The feature's name
|
||||
{{note| '''Note:''' In Eiffel every feature of a class must have a name that is unique within that class. }}
|
||||
{{note|In Eiffel every feature of a class must have a name that is unique within that class. }}
|
||||
|
||||
* The feature's type (in the case of an attribute or a function)
|
||||
* The feature's formal argument list (in the case of a function or procedure that has arguments)
|
||||
@@ -275,7 +275,7 @@ The precondition part of a feature is introduced by the keyword " <code> require
|
||||
|
||||
This part contains the declarations for any "local entities" used by the feature. Sometimes the computation accomplished in a feature requires the use of entities which are only temporary. It would not be appropriate to make these attributes of the class. So, instead we can use local entities, which have scope only within the feature in which they are declared. In the example, <code> hd_item </code> is available as type <code> WEL_HD_ITEM </code> during the computation of feature <code> insert_text_header_item </code>.
|
||||
|
||||
{{note| '''Note:''' A local entity name must not be the same as any feature of the class in which its feature occurs or the same as any argument name of the feature in which it occurs. }}
|
||||
{{note|A local entity name must not be the same as any feature of the class in which its feature occurs or the same as any argument name of the feature in which it occurs. }}
|
||||
|
||||
===Routine Body===
|
||||
<code>
|
||||
@@ -303,7 +303,7 @@ There are other forms that a routine body can take. Here are some examples of so
|
||||
|
||||
The routine body above is for an "external" routine. External routines are used to represent within Eiffel classes, routines that are written in other languages.
|
||||
|
||||
{{tip| '''Tip:''' Because of the high degree of language interaction provided by Microsoft.NET, it is not necessary in Eiffel for.NET to use externals to use software components from.NET assemblies. Instead, these components are presented to the Eiffel programmer as if they were Eiffel classes. Read more about this in [[Conventions|Conventions]] . }}
|
||||
{{tip|Because of the high degree of language interaction provided by Microsoft.NET, it is not necessary in Eiffel for.NET to use externals to use software components from.NET assemblies. Instead, these components are presented to the Eiffel programmer as if they were Eiffel classes. Read more about this in [[Conventions|Conventions]] . }}
|
||||
|
||||
====Once Routines====
|
||||
<code>
|
||||
|
||||
@@ -209,7 +209,7 @@ You may declare multiple <code> feature </code> statements. This helps you group
|
||||
|
||||
Although the words " <code> Initialization </code>" and " <code> Access </code>" are actually in comments after the <code> feature </code> keyword, some language processing tools apply some significance to these, for example, ordering the groups in "pretty-printed" views of a class. Also, some tools allow you to build templates for creating new classes which have <code> feature </code> clauses already in place for predetermined groups.
|
||||
|
||||
{{tip| '''Tip:''' There is not a technical requirement governing the grouping or ordering of features in a class. It is the option of the producer of a class to group and order the features in some fashion that has some meaning. Many years of Eiffel development experience are reflected in the classes in the Eiffel Base Library. This is a good place to look for examples of well constructed classes. }}
|
||||
{{tip|There is not a technical requirement governing the grouping or ordering of features in a class. It is the option of the producer of a class to group and order the features in some fashion that has some meaning. Many years of Eiffel development experience are reflected in the classes in the Eiffel Base Library. This is a good place to look for examples of well constructed classes. }}
|
||||
|
||||
|
||||
===Invariant===
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
[[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.
|
||||
|
||||
{{note| '''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?] }}
|
||||
{{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==
|
||||
|
||||
|
||||
Reference in New Issue
Block a user