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:
halw
2009-10-07 21:54:42 +00:00
parent a066ff77b0
commit 19a4e3f5d3
2 changed files with 27 additions and 1 deletions

View File

@@ -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