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

Added parent qualification to Precursor section.

Browse Source 
Author:halw
Date:2010-10-02T15:34:50.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@684 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2010-10-02 15:34:50 +00:00
parent 85c4be6cab
commit ce016133bf
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -75,12 +75,22 @@ 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 '''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
... Instructions to update the interest ...
</code>
In the event that a routine has redefined a particular feature from multiple parent, the <code>Precursor</code> syntax allows the inclusion of a parent qualification:
<code>
Precursor {PARENT_X} (args...)
-- Apply PARENT_X's version of this feature
... Instructions to update the interest ...
</code>
Besides changing the implementation of a routine, a redefinition can turn an argument-less function into an attribute; for example a proper descendant of <code>ACCOUNT</code> could redefine <code>deposits_count</code>, originally a function, as an attribute. The Uniform Access Principle (introduced in [[ET: The Dynamic Structure: Execution Model|The Dynamic Structure: Execution Model]] ) guarantees that the redefinition makes no change for clients, which will continue to use the feature under the form
<code>
acc.deposits_count