diff --git a/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki b/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki index cbf444db..62dc73de 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki @@ -406,37 +406,65 @@ For entities of reference types, the value of x will be a void refe For entities of expanded types, the values are objects; the object attached to x will be overwritten with the contents of the object attached to y. In the case of atomic objects, as in n := 3 with the declaration n: INTEGER , this has the expected effect of assigning to n the integer value 3; in the case of composite objects, this overwrites the fields for x, one by one, with the corresponding y fields. -To copy an object, use x.copy (y) which assumes that both x and y are non-void, and copies the contents of y's attached object onto those of x's. For expanded entities the effect is the same as that the of the assignment x := y. +To copy an object, use + + x.copy (y) + +which assumes that both x and y are non-void, and copies the contents of y's attached object onto those of x's. For expanded entities the effect is the same as that the of the assignment x := y. An operation performing similar duty to the copy is twin . The assignment x := y.twin -produces a newly created object (provided that y is non-void), initialized with a copy of the object attached to y and attaches the result to x . This means we may view twin as a function that performs the following two steps: +produces a newly created object (provided that y is non-void), initialized with a copy of the object attached to y and attaches the result to x . This means we may view twin as a function that performs the following two steps: create Result Result.copy (Current) The new object is created, then its content is updated to match the content of y to which the twin call is targeted. -So, assuming both entities of reference types and y not void, the assignment above will attach x to a '''new object''' identical to y's attached object, as opposed to the assignment x := y which attaches x to the '''same object''' as y. +So, assuming both entities of reference types and y not void, the assignment above will attach x to a '''new object''' identical to y's attached object, as opposed to the assignment x := y which attaches x to the '''same object''' as y. -To determine whether two values are equal, use the expression x = y . For references, this comparison will yield true if the values are either both void or both attached to the same object; this is the case in the last figure in the state after the assignment, but not before. The symbol for not equal is /= , as in x /= y . +To determine whether two values are equal, use the expression: -As with assignment, there is also a form that works on objects rather than references: x.is_equal (y) will return true when x and y are both non-void and attached to field-by-field identical objects. This can be true even when x = y is not, for example, in the figure, ''before'' the assignment, if the two objects shown are field-by-field equal. + + x = y + +For references, this comparison will yield true if the values are either both void or both attached to the same object; this is the case in the last figure in the state after the assignment, but not before. The symbol for not equal is /= , as in: + + x /= y + -The expression x.is_equal (y) can also be expressed in a notation analogous to x = y. The expression x ~ y will be true only in cases in which x.is_equal (y) is true. +As with assignment, there is also a form that works on objects rather than references: + + x.is_equal (y) + +will return true when x and y are both non-void and attached to field-by-field identical objects. This can be true even when x = y is not, for example, in the figure, ''before'' the assignment, if the two objects shown are field-by-field equal. -A more general variant of is_equal is used under the form equal (x, y) . This is always defined, even if x is void, returning true whenever is_equal would but also if x and y are both void. (In contrast, x.is_equal (y) is not defined for void x and would, if evaluated, yield an exception as explained in [[8 Design by Contract (tm), Assertions and Exceptions#Exception_handling|"Exception handling"]] below.) +The expression x.is_equal (y) can be written alternatively in a notation similar in form to x = y . The expression: + + x ~ y + +will be true only in cases in which x.is_equal (y) is true. -Void denotes a void reference. So you can make x void through the assignment x := Void, and test whether it is void through: +A more general variant of is_equal is used under the form: + + equal (x, y) + +This is always defined, even if x is void, returning true whenever is_equal would but also if x and y are both void. (In contrast, x.is_equal (y) is not defined for void x and would, if evaluated, yield an exception as explained in [[8 Design by Contract (tm), Assertions and Exceptions#Exception_handling|"Exception handling"]] below.) + +Void denotes a void reference. So you can make x void through the assignment + + x := Void + +and test whether it is void through: if x = Void then ... -Where assignment, := , and the equality operators, = and /= , were language constructions, copy, twin, is_equal, and equal are '''library features''' coming from class ANY . +Note that the assignment, := , and the equality operators, =, ~, /~, and /= , are language constructions, whereas copy, twin, is_equal, and equal are '''library features''' coming from class ANY . -Void is a language keyword with built-in functionality, but it is not far out of bounds to think of Void as another feature declared in ANY , but with type of NONE, the "bottom" type. +Void is a language keyword with built-in functionality, but it is not harmful to think of Void as another feature declared in ANY , but with type of NONE, the "bottom" type. Using the redefinition mechanisms to be seen in the discussion of inheritance, a class can redefine copy and is_equal to cover specific notions of copy and equality. The assertions will ensure that the two remain compatible: after x.copy (y) , the property x .is_equal (y) must always be true. The effect of twin will automatically follow a redefinition of copy, and equal will follow is_equal. @@ -558,7 +586,7 @@ Starting a system execution, as we have seen, consists in creating an instance o From then on only two events can change the current object and current procedure: a qualified routine call; and the termination of a routine. -In a call of the form target.routine (...) , targetdenotes a certain object TC. (If not, that is to say, if the value of target is void, attempting to execute the call will trigger an exception, as studied below.) The generating class of TC must, as per the Feature Call rule, contain a routine of name routine. As the call starts, TC becomes the new current object and routine becomes the new current routine. +In a call of the form target.routine (...) , target denotes a certain object TC. (If not, that is to say, if the value of target is void, attempting to execute the call will trigger an exception, as studied below.) The generating class of TC must, as per the Feature Call rule, contain a routine of name routine. As the call starts, TC becomes the new current object and routine becomes the new current routine. When a routine execution terminates, the target object and routine of the most recent non-terminated call -- which, just before just before the terminated call, were the current object and the current routine -- assume again the role of current object and current routine. diff --git a/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki b/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki index 2601f7e4..9b2047e4 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki @@ -2,64 +2,66 @@ [[Property:link_title|ET: Genericity and Arrays]] [[Property:weight|-9]] [[Property:uuid|7f3bd1d7-357e-031d-9faa-b00594aa9ae0]] -Some of the classes that we will need, particularly in libraries, are '''container''' classes, describing data structures made of a number of objects of the same or similar types. Examples of containers include arrays, stacks and lists. The class DEPOSIT_LIST posited in earlier examples describes containers. +Some of the classes that we will need, particularly in libraries, are '''container''' classes, describing data structures made of a number of objects of the same or similar types. Examples of containers include arrays, stacks and lists. The class DEPOSIT_LIST posited in earlier examples describes containers. -It is not hard, with the mechanisms seen so far, to write the class DEPOSIT_LIST , which would include such features as count (query returning the number of deposit objects in the list) and put (command to insert a new deposit object). +It is not hard, with the mechanisms seen so far, to write the class DEPOSIT_LIST, which would include such features as count (query returning the number of deposit objects in the list) and put (command to insert a new deposit object). Most of the operations, however, would be the same for lists of objects other than deposits. To avoid undue replication of efforts and promote reuse, we need a way to describe '''generic''' container classes, which we can use to describe containers containing elements of many different types. ==Making a class generic== The notation -class C [G] ... The rest as for any other class declaration ... - -introduces a generic class. A name such as G appearing in brackets after the class name is known as a '''formal generic parameter'''; it represents an arbitrary type. - -Within the class text, feature declarations can freely use G even though it is not known what type G stands for. Class LIST of EiffelBase, for example, includes features -first: G - -- Value of first list item +class C [G] + ... The rest as for any other class declaration ... -extend (val: G) is - -- Add a new item of value val at end of list -... +introduces a generic class. A name such as G appearing in brackets after the class name is known as a '''formal generic parameter'''; it represents an arbitrary type. + +Within the class text, feature declarations can freely use G even though it is not known what type G stands for. Class LIST of EiffelBase, for example, includes features + + first: G + -- Value of first list item + + extend (val: G) is + -- Add a new item of value val at end of list + ... -The operations available on an entity such as first and val , whose type is a formal generic parameter, are the operations available on all types: use as source y of an assignment x := y , use as target x of such an assignment (although not for val , which as a formal routine argument is not writable), use in equality comparisons x = y or x /= y , and application of universal features from ANY such as clone , equal and copy . +The operations available on an entity such as first and val, whose type is a formal generic parameter, are the operations available on all types: use as source y of an assignment x := y, use as target x of such an assignment (although not for val, which as a formal routine argument is not writable), use in equality comparisons x = y or x /= y, and application of universal features from ANY such as clone, equal and copy. -To use a generic class such as list, a client will provide a type name as '''actual generic parameter'''. So instead of relying on a special purpose class DEPOSIT_LIST , the class ACCOUNT could include the declaration +To use a generic class such as list, a client will provide a type name as '''actual generic parameter'''. So instead of relying on a special purpose class DEPOSIT_LIST, the class ACCOUNT could include the declaration all_deposits: LIST [DEPOSIT] -using LIST as a generic class and DEPOSIT as the actual generic parameter. Then all features declared in LIST as working on values of type G will work, when called on the target all_deposits , on values of type DEPOSIT . With the target +using LIST as a generic class and DEPOSIT as the actual generic parameter. Then all features declared in LIST as working on values of type G will work, when called on the target all_deposits, on values of type DEPOSIT. With the target all_accounts: LIST [ACCOUNT] -these features would work on values of type ACCOUNT . +these features would work on values of type ACCOUNT. {{info|A note of terminology: to avoid confusion, Eiffel always uses the word '''argument''' for routine arguments, reserving '''parameter''' for the generic parameters of classes. }} -Genericity reconciles extendibility and reusability with the static type checking demanded by reliability. A typical error, such as confusing an account and a deposit, will be detected immediately at compile time, since the call all_accounts . extend ( dep ) is invalid for dep declared of type DEPOSIT . What is valid is something like all_accounts . extend ( acc ) for acc of type ACCOUNT . In other approaches, the same effect might require costly run-time checks (as in Java, C# or Smalltalk), with the risk of run-time errors. +Genericity reconciles extendibility and reusability with the static type checking demanded by reliability. A typical error, such as confusing an account and a deposit, will be detected immediately at compile time, since the call all_accounts. extend ( dep ) is invalid for dep declared of type DEPOSIT. What is valid is something like all_accounts. extend ( acc ) for acc of type ACCOUNT. In other approaches, the same effect might require costly run-time checks (as in Java, C# or Smalltalk), with the risk of run-time errors. -{{info|This form of genericity is known as '''unconstrained''' because the formal generic parameter, G in the example, represents an arbitrary type. You may also want to use types that are guaranteed to have certain operations available. This is known as '''constrained''' genericity and will be studied with inheritance. }} +{{info|This form of genericity is known as '''unconstrained''' because the formal generic parameter, G in the example, represents an arbitrary type. You may also want to use types that are guaranteed to have certain operations available. This is known as '''constrained''' genericity and will be studied with inheritance. }} ==Arrays== -An example of generic class from the Kernel Library is ARRAY [ G ] , which describes direct-access arrays. Features include: -* put to replace an element's value, as in my_array . put ( val , 25 ) which replaces by val the value of the array entry at index 25. -* item to access an entry, as in my_array . item ( 25 ) yielding the entry at index 25. A synonym is infix "@" , so that you may also write more tersely, for the same result, my_array @ 25 . -* lower , upper and count : queries yielding the bounds and the number of entries. -* The creation procedure make , as in create my_array . make ( 1, 50 ) which creates an array with the given index bounds. It is also possible to resize an array through resize , retaining the old elements. In general, the Eiffel method abhors built-in limits, favoring instead structures that resize themselves when needed, either from explicit client request or automatically. +An example of generic class from the Kernel Library is ARRAY [ G ], which describes direct-access arrays. Features include: +* put to replace an element's value, as in my_array. put ( val, 25 ) which replaces by val the value of the array entry at index 25. +* item to access an entry, as in my_array. item ( 25 ) yielding the entry at index 25. A synonym is infix "@", so that you may also write more tersely, for the same result, my_array @ 25. +* lower, upper and count: queries yielding the bounds and the number of entries. +* The creation procedure make, as in create my_array. make ( 1, 50 ) which creates an array with the given index bounds. It is also possible to resize an array through resize, retaining the old elements. In general, the Eiffel method abhors built-in limits, favoring instead structures that resize themselves when needed, either from explicit client request or automatically. -The comment made about INTEGER and other basic classes applies to ARRAY too: Eiffel compilers know about this class, and will be able to process expressions of the form my_array . put ( val , 25 ) and my_array @ 25 in essentially the same way as a C or Fortran array access -- my_array [ 25 ] in C. But it is consistent and practical to let developers treat ARRAY as a class and arrays as objects; many library classes in EiffelBase, for example, inherit from ARRAY . Once again the idea is to get the best of both worlds: the convenience and uniformity of the object-oriented way of thinking; and the efficiency of traditional approaches. +The comment made about INTEGER and other basic classes applies to ARRAY too: Eiffel compilers know about this class, and will be able to process expressions of the form my_array. put ( val, 25 ) and my_array @ 25 in essentially the same way as a C or Fortran array access -- my_array [ 25 ] in C. But it is consistent and practical to let developers treat ARRAY as a class and arrays as objects; many library classes in EiffelBase, for example, inherit from ARRAY. Once again the idea is to get the best of both worlds: the convenience and uniformity of the object-oriented way of thinking; and the efficiency of traditional approaches. -A similar technique applies to another Kernel Library class, that one not generic: STRING , describing character strings with a rich set of string manipulation features. +A similar technique applies to another Kernel Library class, that one not generic: STRING, describing character strings with a rich set of string manipulation features. ==Generic derivation== -The introduction of genericity brings up a small difference between classes and types. A generic class C is not directly a type since you cannot declare an entity as being of type C : you must use some actual generic parameter T -- itself a type. C [ T ] is indeed a type, but class C by itself is only a type template. +The introduction of genericity brings up a small difference between classes and types. A generic class C is not directly a type since you cannot declare an entity as being of type C: you must use some actual generic parameter T -- itself a type. C [ T ] is indeed a type, but class C by itself is only a type template. -The process of obtaining a type C [ T ] from a general class C is known as a '''generic derivation'''; C [ T ] is a '''generically derived type'''. Type T itself is, recursively, either a non-generic class or again a generically derived type D [ U ] for some D and U , as in LIST [ ARRAY [ INTEGER ]] .) +The process of obtaining a type C [ T ] from a general class C is known as a '''generic derivation'''; C [ T ] is a '''generically derived type'''. Type T itself is, recursively, either a non-generic class or again a generically derived type D [ U ] for some D and U, as in LIST [ ARRAY [ INTEGER ]].) -It remains true, however, that every type is based on a class. The base class of a generically derived type C [ T ] is C . +It remains true, however, that every type is based on a class. The base class of a generically derived type C [ T ] is C. diff --git a/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki b/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki index fe5c8b41..a92db38a 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki @@ -4,7 +4,7 @@ [[Property:uuid|5b286f94-dd63-1169-a64e-74b5f8c5ef14]] When discovering any approach to software construction, however ambitious its goals, it is reassuring to see first a small example of the big picture -- a complete program to print the famous "Hello World" string. Here is how to perform this fascinating task in the Eiffel notation. -You write a class HELLO with a single procedure, say make , also serving as creation procedure. If you like short texts, here is a minimal version: +You write a class HELLO with a single procedure, say make, also serving as creation procedure. If you like short texts, here is a minimal version: class HELLO @@ -50,31 +50,31 @@ The two versions perform identically; the following comments will cover the more Note the absence of semicolons and other syntactic clatter or clutter. You may in fact use semicolons to separate instructions and declarations. But the language's syntax is designed to make the semicolon optional (regardless of text layout) and it's best for readability to omit it, except in the special case of successive elements on a single line. -The indexing clause does not affect execution semantics; you may use it to associate documentation with the class, so that browsers and other indexing and retrieval tools can help users in search of reusable components satisfying certain properties. Here we see two indexing entries, labeled description and author . +The indexing clause does not affect execution semantics; you may use it to associate documentation with the class, so that browsers and other indexing and retrieval tools can help users in search of reusable components satisfying certain properties. Here we see two indexing entries, labeled description and author. -The name of the class is HELLO . Any class may contain "features"; HELLO has just one, called make . The create clause indicates that make is a "creation procedure", that is to say an operation to be executed at class instantiation time. The class could have any number of creation procedures. +The name of the class is HELLO. Any class may contain "features"; HELLO has just one, called make. The create clause indicates that make is a "creation procedure", that is to say an operation to be executed at class instantiation time. The class could have any number of creation procedures. -The definition of make appears in a feature clause. There may be any number of such clauses (to separate features into logical categories), and each may contain any number of feature declarations. Here we have only one. +The definition of make appears in a feature clause. There may be any number of such clauses (to separate features into logical categories), and each may contain any number of feature declarations. Here we have only one. -The line starting with -- (two hyphen signs) is a comment; more precisely it is a "header comment", which style rules invite software developers to write for every such feature, just after the point at which the feature is named. As will be seen in [[8 Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]], the tools of EiffelStudio know about this convention and use it to include the header comment in the automatically generated class documentation. +The line starting with -- (two hyphen signs) is a comment; more precisely it is a "header comment", which style rules invite software developers to write for every such feature, just after the point at which the feature is named. As will be seen in [[8 Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]], the tools of EiffelStudio know about this convention and use it to include the header comment in the automatically generated class documentation. -The body of the feature is introduced by the do keyword and terminated by end . It consists of two output instructions. They both use io , a generally available reference to an object that provides access to standard input and output mechanisms; the notation io.f, for some feature f of the corresponding library class ( STD_FILES , in this case), means "apply f to io". Here we use two such features: -* put_string outputs a string, passed as argument, here "Hello World" . -* put_new_line terminates the line. +The body of the feature is introduced by the do keyword and terminated by end. It consists of two output instructions. They both use io, a generally available reference to an object that provides access to standard input and output mechanisms; the notation io.f, for some feature f of the corresponding library class (STD_FILES, in this case), means "apply f to io". Here we use two such features: +* put_string outputs a string, passed as argument, here "Hello World". +* put_new_line terminates the line. -Rather than using a call to put_new_line , the first version of the class simply includes a new-line character, denoted as %N , at the end of the string. Either technique is acceptable. +Rather than using a call to put_new_line, the first version of the class simply includes a new-line character, denoted as %N , at the end of the string. Either technique is acceptable. You may have noticed another difference between the two versions. The first version uses a call to print where the second uses io.put_string . Here too, the effect is identical and either technique is acceptable. In the next section, you will begin to see how things like io and print become available for use in a class like HELLO. To build the system and execute it: * Start EiffelStudio * Create a new ''Basic application'' project -* Specify HELLO as the "root class" and make as the "root procedure". -* You can either use EiffelStudio to type in the above class text, or you may use any text editor and store the result into a file hello.e in the current directory. +* Specify HELLO as the "root class" and make as the "root procedure". +* You can either use EiffelStudio to type in the above class text, or you may use any text editor and store the result into a file hello.e in the current directory. * Click the "Compile" icon. * Click the "Run" icon. -Execution starts and outputs Hello World on the appropriate medium: under Windows, a Console; under Unix or OpenVMS, the windows from which you started EiffelStudio. +Execution starts and outputs Hello World on the appropriate medium: under Windows, a Console; under Unix or OpenVMS, the windows from which you started EiffelStudio. diff --git a/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki b/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki index e2047d74..07111546 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki @@ -48,7 +48,7 @@ Complementing the preceding principles is the idea that, in the cluster lifecycl The preceding goals benefit from the ability to check frequently that the current iteration is correct and robust. Eiffel supports efficient compilation mechanisms through such mechanisms as the '''Melting Ice Technology''' in EiffelStudio. The Melting Ice achieves immediate recompilation after a change, guaranteeing a recompilation time that's a function of the size of the changes, not of the system's overall size. Even for a system of several thousand classes and several hundred thousand lines, the time to get restarted after a change to a few classes is, on a typical modern computer, a few seconds. -Such a "melt" (recompilation) will immediately catch (along with any syntax errors) the type errors -- often the symptoms of conceptual errors that, if left undetected, could cause grave damage later in the process or even during operation. Once the type errors have been corrected, the developers should start testing the new functionalities, relying on the power of '''assertions''' -- explained in [[8 Design by Contract (tm), Assertions and Exceptions|"Design By Contract™ Assertions, Exceptions", page 38 ]] -- to kill the bugs while they are still larvae. Such extensive unit and system testing, constantly interleaved with development, plays an important part in making sure that the "current demo" is trustworthy and will eventually yield a correct and robust product. +Such a "melt" (recompilation) will immediately catch (along with any syntax errors) the type errors -- often the symptoms of conceptual errors that, if left undetected, could cause grave damage later in the process or even during operation. Once the type errors have been corrected, the developers should start testing the new functionalities, relying on the power of '''assertions''' -- explained in [[8 Design by Contract (tm), Assertions and Exceptions|"Design By Contract™ Assertions, Exceptions"]] -- to kill the bugs while they are still larvae. Such extensive unit and system testing, constantly interleaved with development, plays an important part in making sure that the "current demo" is trustworthy and will eventually yield a correct and robust product. ==Quality and functionality== diff --git a/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki b/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki index def7b318..9994c8fa 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki @@ -12,42 +12,42 @@ An Eiffel system is a collection of classes, one of which is designated as the r To execute such a system is to create an instance of the root class (an object created according to the class description) and to execute the root procedure. In anything more significant than "Hello World" systems, this will create new objects and apply features to them, in turn triggering further creations and feature calls. -For the system to make sense, it must contains all the classes on which the root '''depends''' directly or indirectly. A class B depends on a class A if it is either a '''client''' of A , that is to say uses objects of type A , or an '''heir''' of A , that is to say extends or specializes A . (These two relations, client and inheritance, are covered below.) +For the system to make sense, it must contains all the classes on which the root '''depends''' directly or indirectly. A class B depends on a class A if it is either a '''client''' of A, that is to say uses objects of type A, or an '''heir''' of A, that is to say extends or specializes A. (These two relations, client and inheritance, are covered below.) ==Classes== The notion of class is central to the Eiffel approach. A class is the description of a type of run-time data structures (objects), characterized by common operations features) and properties. Examples of classes include: -* In a banking system, a class ACCOUNT may have features such as deposit , adding a certain amount to an account, all_deposits , yielding the list of deposits since the account's opening, and balance , yielding the current balance, with properties stating that deposit must add an element to the all_deposits list and update balance by adding the sum deposited, and that the current value of balance must be consistent with the lists of deposits and withdrawals. -* A class COMMAND in an interactive system of any kind may have features such as execute and undo , as well as a feature undoable which indicates whether a command can be undone, with the property that undo is only applicable if undoable yields the value true. -* A class LINKED_LIST may have features such as put , which adds an element to a list, and count , yielding the number of elements in the list, with properties stating that put increases count by one and that count is always non-negative. +* In a banking system, a class ACCOUNT may have features such as deposit, adding a certain amount to an account, all_deposits, yielding the list of deposits since the account's opening, and balance, yielding the current balance, with properties stating that deposit must add an element to the all_deposits list and update balance by adding the sum deposited, and that the current value of balance must be consistent with the lists of deposits and withdrawals. +* A class COMMAND in an interactive system of any kind may have features such as execute and undo , as well as a feature undoable which indicates whether a command can be undone, with the property that undo is only applicable if undoable yields the value true. +* A class LINKED_LIST may have features such as put, which adds an element to a list, and count, yielding the number of elements in the list, with properties stating that put increases count by one and that count is always non-negative. We may characterize the first of these examples as an analysis class, directly modeling objects from the application domain; the second one as a design class, describing a high-level solution; and the third as an implementation class, reused whenever possible from a library such as EiffelBase. In Eiffel, however, there is no strict distinction between these categories; it is part of the approaches seamlessness that the same notion of class, and the associated concepts, may be used at all levels of the software development process. ==Class relations== Two relations may exist between classes: -* You can define a class C as a '''client''' of a class A to enable the features of C to rely on objects of type A . -* You may define a class B as an '''heir''' of a class A to provide B with all the features and properties of A , letting B add its own features and properties and modify some of the inherited features if appropriate. +* You can define a class C as a '''client''' of a class A to enable the features of C to rely on objects of type A. +* You may define a class B as an '''heir''' of a class A to provide B with all the features and properties of A, letting B add its own features and properties and modify some of the inherited features if appropriate. -If C is a client of A , A is a '''supplier''' of C . If B is an heir of A , A is a '''parent''' of B . A '''descendant''' of A is either A itself or, recursively, a descendant of an heir of A ; in more informal terms a descendant is a direct or indirect heir, or the class itself. To exclude A itself we talk of '''proper descendant'''. In the reverse direction the terms are '''ancestor''' and '''proper ancestor'''. +If C is a client of A, A is a '''supplier''' of C. If B is an heir of A, A is a '''parent''' of B. A '''descendant''' of A is either A itself or, recursively, a descendant of an heir of A; in more informal terms a descendant is a direct or indirect heir, or the class itself. To exclude A itself we talk of '''proper descendant'''. In the reverse direction the terms are '''ancestor''' and '''proper ancestor'''. -The client relation can be cyclic; an example involving a cycle would be classes PERSON and HOUSE , modeling the corresponding informal everyday "object" types and expressing the properties that every person has a home and every home has an architect. The inheritance (heir) relation may not include any cycle. +The client relation can be cyclic; an example involving a cycle would be classes PERSON and HOUSE, modeling the corresponding informal everyday "object" types and expressing the properties that every person has a home and every home has an architect. The inheritance (heir) relation may not include any cycle. -In modeling terms, client roughly represents the relation "has" and heir roughly represents "is". For example we may use Eiffel classes to model a certain system and express that every child has a birth date (client relation) and is a person (inheritance). +In modeling terms, client roughly represents the relation "has" and heir roughly represents "is". For example we may use Eiffel classes to model a certain system and express that every child has a birth date (client relation) and is a person (inheritance). Distinctive of Eiffel is the rule that lasses can only be connected through these two relations. This excludes the behind-the-scenes dependencies often found in other approaches, such as the use of global variables, which jeopardize the modularity of a system. Only through a strict policy of limited and explicit inter-class relations can we achieve the goals of reusability and extendibility. ==The global inheritance structure== -An Eiffel class that you write does not come into a vacuum but fits in a preordained structure, shown in the figure and involving two library classes: ANY and NONE . +An Eiffel class that you write does not come into a vacuum but fits in a preordained structure, shown in the figure and involving two library classes: ANY and NONE. [[Image:tutorial-4]] -Any class that does not explicitly inherit from another is considered to inherit from ANY , so that every class is a descendant, direct or indirect, of ANY . ANY introduces a number of general-purpose features useful everywhere, such as copying, cloning and equality testing operations (page [[6 The Dynamic Structure: Execution Model|28]] ) and default input-output. The procedure print used in the first version of our "Hello World" (page [[4 Hello World|11]] ) comes from ANY . +Any class that does not explicitly inherit from another is considered to inherit from ANY, so that every class is a descendant, direct or indirect, of ANY. ANY introduces a number of general-purpose features useful everywhere, such as copying, cloning and equality testing operations (page [[6 The Dynamic Structure: Execution Model|28]] ) and default input-output. The procedure print used in the first version of our "Hello World" (page [[4 Hello World|11]] ) comes from ANY. - NONE inherits from any class that has no explicit heir. Since inheritance has no cycles, NONE cannot have proper descendants. This makes it useful, as we will see, to specify non-exported features, and to denote the type of void values. Unlike ANY , class NONE doesn't have an actual class text; instead, it's a convenient fiction. +NONE inherits from any class that has no explicit heir. Since inheritance has no cycles, NONE cannot have proper descendants. This makes it useful, as we will see, to specify non-exported features, and to denote the type of void values. Unlike ANY, class NONE doesn't have an actual class text; instead, it's a convenient fiction. ==Clusters== @@ -66,7 +66,7 @@ file_status (filedesc: INTEGER): INTEGER end -to indicate that it is actually an encapsulation of a C function whose original name is fstat _ . The alias clause is optional, but here it is needed because the C name, starting with an underscore, is not valid as an Eiffel identifier. +to indicate that it is actually an encapsulation of a C function whose original name is fstat _. The alias clause is optional, but here it is needed because the C name, starting with an underscore, is not valid as an Eiffel identifier. Similar syntax exists to interface with C++ classes. EiffelStudio includes a tool called Legacy++ which will automatically produce, from a C++ class, an Eiffel class that encapsulates its facilities, making them available to the rest of the Eiffel software as bona fide Eiffel features.