diff --git a/documentation/22.12/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki b/documentation/22.12/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki index 51bd61cc..5862ca91 100644 --- a/documentation/22.12/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki +++ b/documentation/22.12/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki @@ -1,3 +1,5 @@ +[[Property:modification_date|Mon, 23 Jan 2023 08:51:31 GMT]] +[[Property:publication_date|Mon, 23 Jan 2023 08:51:31 GMT]] [[Property:title|I2E: Classes]] [[Property:weight|-11]] [[Property:uuid|218bead9-428e-f61d-1e45-7eea4291d895]] @@ -40,7 +42,7 @@ These feature calls use dot notation, of the form target_name.feature_name Routines are further divided into '''procedures''' (commands, which do not return a value) and '''functions''' (queries, returning a value). Here may_withdraw is a function returning a boolean; the other three-routines called are procedures. -{{info|A note on syntax: you may separate instructions by semicolons, and indeed you should when, as on the next-to-last line of the example, two or more instructions appear on a line. But the language's syntax has been designed so that the semicolon is almost always optional, regardless of the layout. Indeed the practice is to omit it between instructions or declarations on separate lines, as this results in lighter, clearer software texts. }} +{{info|A note on syntax: you may separate instructions by semicolons, and indeed you should when, as on the next-to-last line of the example, two or more instructions appear on a line. But the language's syntax has been designed so that the semicolon is almost always optional, regardless of the layout. Indeed the practice is to omit it between instructions or declarations on separate lines, as this results in lighter, clearer software texts. Such as `acc.withdraw (3000); print (acc.balance)` }} In class ACCOUNT, is feature balance an attribute, or is it a function with no argument? The above extract of the client class X doesn't say, and this ambiguity is intentional. A client of ACCOUNT must not need to know how class ACCOUNT delivers an account's balance when requested: by looking up a field present in each account object, or by calling a function that computes the balance from other fields. Choosing between these techniques is the business of class ACCOUNT, not anybody else's. Because such implementation choices are often changed over the lifetime of a project, it is essential to protect clients against their effects. This is known as the '''Uniform Access Principle''', stating that the choice between representing a property through memory (an attribute) or through an algorithm (function) shall not affect how clients use it.