mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-06 14:52:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:admin

Browse Source 
Date:2008-09-28T19:42:04.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@55 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
jfiat
2008-09-28 19:42:04 +00:00
parent 7d2dc42293
commit ee798d2560
3 changed files with 2 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/current/_templates/Caution.tpl
View File

@@ -1,2 +1,2 @@
<p style="margin-left: 10px; margin-right: 50px; border: 1px solid #ff5c5c; padding: 10px; background-color: #FFeFeF; color: black;">[[Image:LogoWarning|24px]] '''Caution:''' {{{1}}}</p>
<p style="margin-left: 10px; margin-right: 50px; border: 1px solid #FFB55F; padding: 10px; background-color: #FFEEBF; color: black;">[[Image:LogoWarning|24px]] '''Caution:''' {{{1}}}</p>

3
documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
View File

@@ -96,8 +96,7 @@ which will assign to <code> acc </code> a reference attached (if not void) to a
Such an assignment, where the source and target types are different, is said to be polymorphic. An entity such as <code> acc </code>, which as a result of such assignments may become attached at run time to objects of types other than the one declared for it, is itself called a polymorphic entity.
For polymorphism to respect the reliability requirements of Eiffel, it must be controlled by the type system and enable static type checking. We certainly do not want an entity of type <code> ACCOUNT </code> to become attached to an object of type <code> DEPOSIT </code>. Hence the second typing rule:
{{note| '''Type Conformance rule '''An assignment <code>x := y</code>, or the use of y as actual argument corresponding to the formal argument x in a routine call, is only valid if the type of y conforms to the the type of x . }}
{{rule|Type Conformance|An assignment <code>x := y</code>, or the use of y as actual argument corresponding to the formal argument x in a routine call, is only valid if the type of y conforms to the the type of x. }}
The second case listed in the rule is a call such as <code> target.routine(..., y, ...) </code> where the routine declaration is of the form <code> routine (..., x: SOME_TYPE) </code>. The relationship between <code> y </code>, the actual argument in the call, and the corresponding formal argument <code> x </code>, is exactly the same as in an assignment <code> x := y </code>: not just the type rule, as expressed by Type Conformance (the type of <code> y </code> must conform to <code> SOME_TYPE </code>), but also the actual run-time effect which, as for assignments, will be either a reference attachment or, for expanded types, a copy.

10
documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki
View File

@@ -9,14 +9,4 @@ The highest-level class is [[ref:libraries/base/reference/container_chart| CONTA
* [[ref:libraries/base/reference/box_chart|BOX]] , which describes their storage properties, such as being bounded or unbounded.
The documentation further discusses:
* The [[EiffelBase, Abstract Container Structures: The Taxonomy|taxonomy]] of the abstract container structures.
* The [[EiffelBase Data Structures, Lists|list-based structures hierarchy]] .
* The [[EiffelBase, Dispensers|dispenser-based structures hierarchy]] .
* The [[EiffelBase, Trees|tree-based structures hierarchy]] .
* The [[EiffelBase, Sets|set-based structures hierarchy]] .
* The [[EiffelBase, Tables|table-based structures hierarchy]] .
* The [[EiffelBase, Iteration|iteration mechanisms]] .