mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-07 07:12:25 +01:00
Author:halw
Date:2009-10-07T21:54:42.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@322 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
@@ -72,7 +72,7 @@ end -- class SAVINGS_ACCOUNT
|
||||
|
||||
Without the <code>redefine</code> subclause, the declaration of <code>deposit</code> would be invalid, yielding two features of the same name, the inherited one and the new one. The subclause makes this valid by specifying that the new declaration will override the old one.
|
||||
|
||||
In a redefinition, the original version -- such as the <code>ACCOUNT</code> implementation of <code>deposit</code> in this example -- is called the <code>precursor</code> of the new version. It is common for a redefinition to rely on the precursor's algorithm and add some other actions; the reserved word <code>Precursor</code> helps achieve this goal simply. Permitted only in a routine redefinition, it denotes the parent routine being redefined. So here the body of the new <code>deposit</code> (called "New implementation" above) could be of the form
|
||||
In a redefinition, the original version -- such as the <code>ACCOUNT</code> implementation of <code>deposit</code> in this example -- is called the '''precursor''' of the new version. It is common for a redefinition to rely on the precursor's algorithm and add some other actions; the reserved word <code>Precursor</code> helps achieve this goal simply. Permitted only in a routine redefinition, it denotes the parent routine being redefined. So here the body of the new <code>deposit</code> (called "New implementation" above) could be of the form
|
||||
<code>
|
||||
Precursor (sum)
|
||||
-- Apply ACCOUNT's version of deposit
|
||||
|
||||
@@ -315,18 +315,44 @@ The logical negation [[Eiffel language syntax#Operators|operator]].
|
||||
|
||||
===note===
|
||||
|
||||
Used to begin a Notes part, in either a [[Eiffel language syntax#Class declarations|class declaration]] or a [[Eiffel language syntax#Check instructions|check instruction]].
|
||||
|
||||
:[[Eiffel language syntax#Notes|Syntax.]]
|
||||
|
||||
|
||||
===obsolete===
|
||||
|
||||
Used to mark [[ET: Other Mechanisms#Obsolete features and classes|obsolete features and classes]].
|
||||
|
||||
:[[Eiffel language syntax#Feature declarations|Feature declarations syntax.]]
|
||||
|
||||
:[[Eiffel language syntax#Class declarations|Class declarations declarations syntax.]]
|
||||
|
||||
:[[Eiffel language syntax#Obsolete marks|Obsolete mark syntax.]]
|
||||
|
||||
|
||||
===old===
|
||||
|
||||
Introduces an ''old expression''. Old expressions are valid only in the [[ET: Design by Contract (tm), Assertions and Exceptions#Postconditions|postconditions]] of routines.
|
||||
|
||||
:[[Eiffel language syntax#Old postcondition expressions|Syntax.]]
|
||||
|
||||
|
||||
===once===
|
||||
|
||||
Used to introduce [[ET: Other Mechanisms#Once routines and shared objects|once routines]] and once string expressions.
|
||||
|
||||
:[[Eiffel language syntax#Routine bodies|Once routine syntax.]]
|
||||
|
||||
:[[Eiffel language syntax#Expressions|Once string syntax.]]
|
||||
|
||||
|
||||
===only===
|
||||
|
||||
Used in an ''only postcondition clause''. (8.9.11)
|
||||
|
||||
:[[Eiffel language syntax#"Old" postcondition expressions|Syntax.]]
|
||||
|
||||
|
||||
===or===
|
||||
|
||||
|
||||
Reference in New Issue
Block a user