diff --git a/documentation/current/_templates/Rule.tpl b/documentation/current/_templates/Rule.tpl index ad18cc00..d20055c7 100644 --- a/documentation/current/_templates/Rule.tpl +++ b/documentation/current/_templates/Rule.tpl @@ -1 +1 @@ -

[[Image:LogoInformation|24px]] '''Rule -- {{{1}}}:''' {{{2}}}

+

[[Image:LogoInformation|24px]] '''Rule -- {{{name}}}:''' {{{text}}}

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 dbd1f524..63e603f7 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 @@ -2,7 +2,7 @@ [[Property:link_title|ET: The Dynamic Structure: Execution Model]] [[Property:weight|-10]] [[Property:uuid|1f3f2707-9129-4dca-76c7-157143d7ae74]] -A system with a certain static structure describes a set of possible executions. The run-time model governs the structure of the data ( objects ) created during such executions. +A system with a certain static structure describes a set of possible executions. The run-time model governs the structure of the data (objects) created during such executions. The properties of the run-time model are not just of interest to implementers; they also involve concepts directly relevant to the needs of system modelers and analysts at the most abstract levels. diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki index eeace52e..63cd2aa9 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki @@ -250,7 +250,7 @@ Rather than using a separate method and notation for analysis and design, this a The following sketch (from the book [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] ) illustrates these ideas on theexample of scheduling the programs of a TV station. This is pure modeling of an application domain; no computers or software are involved yet. The class describes the notion of program segment. -Note the use of assertions to define semantic properties of the class, its instances and its features. Although often presented as high-level, most object-oriented analysis methods (with the exception of Waldn's and Nerson's Business Object Notation) have no support for the expression of such properties, limiting themselves instead to the description of broad structural relationships. +Note the use of assertions to define semantic properties of the class, its instances and its features. Although often presented as high-level, most object-oriented analysis methods (with the exception of Walden's and Nerson's Business Object Notation) have no support for the expression of such properties, limiting themselves instead to the description of broad structural relationships. indexing description: "Individual fragments of a broadcasting schedule" @@ -398,7 +398,7 @@ Here both LIST and ARRAY have features called B as an instance of A , then every consistency constraint on instances of A must also apply to instances of B . @@ -433,7 +433,7 @@ The rule, then, is that for the redefinition to be correct the new precondition Because it is impossible to check simply that an assertion is weaker or stronger than another, the language rule relies on different forms of the assertion constructs, else require and then ensure , for redeclared routines. They rely on the mathematical property that, for any assertions p and q, p implies ( p or q ) , and (p and q) implies p . For a precondition, using else require with a new assertion will perform an or , which can only weaken the original; for a postcondition, then ensure will perform an and , which can only strengthen the original. Hence the rule: -{{note| '''Assertion Redeclaration rule''': In the redeclared version of a routine, it is not permitted to use a require or ensure clause. Instead you may: Introduce a new condition with require else, for or-ing with the original precondition. Introduce a new condition with ensure then, for and-ing with the original postcondition. In the absence of such a clause, the original assertions are retained. }} +{{rule|Assertion Redeclaration|In the redeclared version of a routine, it is not permitted to use a require or ensure clause. Instead you may: Introduce a new condition with require else, for or-ing with the original precondition. Introduce a new condition with ensure then, for and-ing with the original postcondition. In the absence of such a clause, the original assertions are retained. }} The last case -- retaining the original -- is frequent but by no means universal. @@ -579,7 +579,7 @@ If there are separate accounts for students' course work and for faculty, you ma The Eiffel rule enables, once again, the software developer to craft the resulting class so as to tune it to the exact requirements. Not surprisingly, it is based on names, in accordance with the Final Name rule (no in-class overloading): -{{note| '''Repeated Inheritance rule:'''
A feature inherited multiply under one name will be shared: it is considered to be just one feature in the repeated descendant.
A feature inherited multiply under different names will be replicated, yielding as many variants as names. }} +{{rule|Repeated Inheritance|
A feature inherited multiply under one name will be shared: it is considered to be just one feature in the repeated descendant.
A feature inherited multiply under different names will be replicated, yielding as many variants as names. }} So to tune the repeated descendant, feature by feature, for sharing and replication it suffices to use renaming. @@ -728,7 +728,7 @@ We introduce an heir BUSINESS_ACCOUNT of ACCOUNT t [[Image:tutorial-14]] Clearly, we must redefine owner in class BUSINESS_ACCOUNT to yield a result of type BUSINESS ; the same signature redefinition must be applied to the argument of set_owner . This case is typical of the general scheme of signature redefinition: in a descendant, you may need to redefine both results and arguments to types conforming to the originals. This is reflected by a language rule: -{{note| '''Covariance rule''': In a feature redeclaration, both the result type if the feature is a query (attribute or function) and the type of any argument if it is a routine (procedure or function) must conform to the original type as declared in the precursor version. }} +{{rule|Covariance|In a feature redeclaration, both the result type if the feature is a query (attribute or function) and the type of any argument if it is a routine (procedure or function) must conform to the original type as declared in the precursor version. }} The term "covariance" reflects the property that all types -- those of arguments and those of results -- vary together in the same direction as the inheritance structure. diff --git a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki index a932ecd6..429e6a6b 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki @@ -143,7 +143,7 @@ end a.r (x) -{{note|the recommended convention: extra indentation of the check part to separate it from the algorithm proper; and inclusion of a comment listing the rationale behind the developer's decision not to check explicitly for the precondition. }} +{{recommended|An extra indentation of the check part to separate it from the algorithm proper; and inclusion of a comment listing the rationale behind the developer's decision not to check explicitly for the precondition. }} In production mode with assertion monitoring turned off, this instruction will have no effect. But it will be precious for a maintainer of the software who is trying to figure out what it does, and in the process to reconstruct the original developer's reasoning. (The maintainer might of course be the same person as the developer, six months later.) And if the rationale is wrong somewhere, turning assertion checking on will immediately uncover the bug. @@ -253,6 +253,7 @@ Features available on tuple types include count: INTEGER , yieldin Tuples are appropriate when these are the only operations you need, that is to say, you are using sequences with no further structure or properties. Tuples give you "anonymous classes" with predefined features count , item and put . A typical example is a general-purpose output procedure that takes an arbitrary sequence of values, of arbitrary types, and prints them. It may simply take an argument of type TUPLE , so that clients can call it under the form + write ([ ''your_integer'' , ''your_real'', ''your_account'']) diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki index f562930e..696ae47f 100644 --- a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki +++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki @@ -5,8 +5,6 @@ This sample consists of a command line reverse Polish notation (RPN) calculator. {{note|A RPN calculator works slightly differently from standard calculators. It consists of a stack of numbers. Operations are applied to the two numbers on top of the stack. The result is then put on top of the stack so that it can be used in the next operation. This sample refers to the top of the stack as ''Accumulator''.This sample consists of a command line reverse Polish notation (RPN) calculator. }} -{{note|A RPN calculator works slightly differently from standard calculators. It consists of a stack of numbers. Operations are applied to the two numbers on top of the stack. The result is then put on top of the stack so that it can be used in the next operation. This sample refers to the top of the stack as ''Accumulator''. }} - ==Compiling== To compile the example: @@ -39,7 +37,7 @@ Enter a number, followed by : Enter the first number to be put onto the stack, for example 3. -{{note|Failing to enter a number at this stage will cause the sample to stop. This sample was designed to showcase the use of EiffelBase data structures and is not protected against unexpected entries. }} +{{caution|Failing to enter a number at this stage will cause the sample to stop. This sample was designed to showcase the use of EiffelBase data structures and is not protected against unexpected entries. }} You may then add another number on the stack by entering the character a: diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/index.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/index.wiki index 10693b75..c9c73cf7 100644 --- a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/index.wiki +++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/index.wiki @@ -1,8 +1,5 @@ [[Property:title|EiffelBase Samples]] [[Property:weight|3]] [[Property:uuid|5095bbdf-0dd6-7d7b-68d4-59a8293950ee]] -* [[EiffelBase Sample: Calculator|Calculator]] - - diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki index 3146f391..3dec2845 100644 --- a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki +++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki @@ -285,7 +285,7 @@ The classes describing list cells are descendants of a deferred class called [[r Class [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] is an effective descendant of [[ref:/libraries/base/reference/cell_chart|CELL]] , used for one-way linked structures. It introduces features right, a reference to another cell to which the current
cell will be linked. Two-way linked structures use [[ref:/libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] , an heir of [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] which to the above features adds left, a reference to the preceding cell in the structure. -{{warning| '''Caution''': Do not confuse the item feature of [[ref:/libraries/base/reference/cell_chart|CELL]] and its descendants, such as [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , with the item feature of the classes describing linear structures, such as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] . For a linked list, item returns the item at cursor position. }} +{{caution|Do not confuse the item feature of [[ref:/libraries/base/reference/cell_chart|CELL]] and its descendants, such as [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , with the item feature of the classes describing linear structures, such as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] . For a linked list, item returns the item at cursor position. }} It may be implemented as item: G is @@ -301,7 +301,7 @@ using the item feature of [[ref:/libraries/base/reference/linka If you look at the interfaces of one-way and two-way linked structures, you will notice that they are almost identical. This is because it is possible to implement features such as back for one-way structures such as described by [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] and [[ref:/libraries/base/reference/linked_circular_chart|LINKED_CIRCULAR]] . A simple implementation of back stores away a reference to the current active item, executes start, and then performs forth until the item to the right of the cursor position is the previous active.
Although correct, such an implementation is of course rather inefficient since it requires a traversal of the list. In terms of algorithmic complexity, it is in O (count), meaning that its execution time is on the average proportional to the number of items in the structure. In contrast, forth is O (1), that is to say, takes an execution time bounded by a constant. -{{warning| '''Caution''': As a consequence, you should not use one-way linked structures if you need to execute more than occasional back operations (and other operations requiring access to previous items, such as remove_left). }} +{{caution|As a consequence, you should not use one-way linked structures if you need to execute more than occasional back operations (and other operations requiring access to previous items, such as remove_left). }} Two-way linked structures, such as those described by [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] and [[ref:/libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] , treat the two directions symmetrically, so that back will be just as efficient as forth. Hence the following important advice: If you need to traverse a linked structure both ways, not just left to right, use the TWO_WAY_ classes, not the LINKED_ versions. The TWO_WAY_ structures will take up more space, since they use [[ref:/libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] rather than [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] cells, but for most applications this space penalty is justified by the considerable gains in time that will result if right-to-left operations are frequently needed. @@ -315,7 +315,7 @@ An instance of [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] , a In contrast, [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] has almost the same interface as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] . In particular, it is possible to add items at the end using procedure extend; if the call causes the list to grow beyond the current array's capacity, it will trigger a resizing. This is achieved by using the procedure force of class ARRAY to implement extend. [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] even has the insertion procedures (put_front, put_left, put_right) and removal procedures (prune, remove, remove_left, remove_right) that apply to arbitrary positions and appear in the linked implementations. These procedures, however, are rather inefficient, since they usually require moving a whole set of array items, an O (count) operation. (Procedure extend does not suffer from this problem, since it is easy to add an item to the end of an array, especially if there is still room so that no resizing is necessary.) -{{warning| '''Caution''': The situation of these features in [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] is similar to the situation of back in classes describing one-way linked structures: it is convenient to include them because they may be needed once in a while and an implementation exists; but using them more than occasionally may result in serious inefficiencies. If you do need to perform arbitrary insertions and removal, use linked structures, not arrayed ones. }} +{{caution|The situation of these features in [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] is similar to the situation of back in classes describing one-way linked structures: it is convenient to include them because they may be needed once in a while and an implementation exists; but using them more than occasionally may result in serious inefficiencies. If you do need to perform arbitrary insertions and removal, use linked structures, not arrayed ones. }} Arrayed structures, however, use up less space than linked representations. So they are appropriate for chains on which, except possibly for insertions at the end, few insertion and removal operations or none at all are expected after creation. [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] offers few advantages over [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] . [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] may be useful, however, for cases in which the fixed number of items is part of the specification, and any attempt to add more items must be treated as an error. For circular chains only one variant is available, [[ref:/libraries/base/reference/arrayed_circular_chart|ARRAYED_CIRCULAR]] , although writing a FIXED_ version would be a simple exercise. @@ -336,7 +336,7 @@ The class [[ref:/libraries/base/reference/comparable_struct_chart|COMPARABLE_STR As indicated by the constrained generic parameter it describes bilinear structures whose items may be compared by a total order relation. -{{warning| '''Caution''': Note that the class name, chosen for brevity's sake, is slightly misleading: it is not the structures that are comparable but their items. }} +{{caution|The class name COMPARABLE_STRUCT, chosen for brevity's sake, is slightly misleading: it is not the structures that are comparable but their items. }} COMPARABLE_STRUCT introduces the features min and max, giving access to the minimum and maximum elements of a structure; these are always present for a finite
structure with a total order relation. [[ref:/libraries/base/reference/sorted_struct_chart|SORTED_STRUCT]] , an heir of [[ref:/libraries/base/reference/comparable_struct_chart|COMPARABLE_STRUCT]] , describes structures that can be sorted; it introduces the query sorted and the command sort.
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel.wiki index 9359d037..197d2640 100644 --- a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel.wiki +++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel.wiki @@ -183,12 +183,12 @@ In particular all tuple types conform to [[ref:/libraries/base/reference/tuple_c to a type T, then TUPLE [T1, T2, ..., Tn] conforms to ARRAY [T] + {{Definition|Tuple Type|A "tuple type" is any type based on class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , i.e. any type of the form TUPLE [T 1, T 2, ..., T n] for any n (including 0, for which there is no generic parameter). }} -{{note|(Note 1: CONF1 should be understood in terms of the underlying mathematical model. Mathematically, [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n] is the set TUPLE n of all partial functions f from N+ (the set of non-negative integers) to T 1 U T 2 U ... T n, such that: -* The domain of f contains the interval 1..n (in other words, f is defined for any i such that 1 <= i <= n). -* For 1 <= i <= n, f (i) is a member of T i. -}} + +{{note|CONF1 should be understood in terms of the underlying mathematical model.
+Mathematically, TUPLE [T1, T2, ..., Tn] is the set TUPLE n of all partial functions f from N+ (the set of non-negative integers) to T1 U T2 U ... Tn, such that:
The domain of f contains the interval 1..n (in other words, f is defined for any i such that 1 <= i <= n).
For 1 <= i <= n, f (i) is a member of Ti. }} With this definition, TUPLE n is indeed a subset of TUPLE n+1, and in particular TUPLE 0, the empty set, is a subset of TUPLE n for any n.) @@ -304,17 +304,17 @@ A few classes of the Kernel Library support file manipulation, input and output: FILE describes the notion of sequential file viewed as a data structure which fits in the general taxonomy of EiffelBase.
The class declaration defines files as unbounded sequences of characters. This means that you will find in FILE all the operations on sequential data structures that you have come to know and love by reading this documentation - at least, all that apply. Just as stacks and linked lists, files have put, extend, has, item and so on. More specific to files are the typed input and output operations. For output, you will find put_character, put_integer, put_real, put_double and put_string, as well as new_line. For input you will find read_integer and its co-conspirators. -{{warning| '''Caution''': Note the application to input features of the command-query separation principle.
+{{caution|Note the application to input features of the command-query separation principle.
The input features such as read_integer do not by themselves return a result; they set the values of queries such as last_integer. So the normal way to read is through two operations:

- my_file . read_integer
- new_value := my_file . last_integer }} +my_file.read_integer
+new_value := my_file.last_integer }} Queries are available to determine the status of a file, in particular exists, is_readable, is_executable, is_writable, is_creatable, is_closed, is_open_read and so on. -{{warning| '''Caution''': You will notice in the flat-short form that all these queries except the first have exists as a precondition. This precondition is good for efficiency since it saves an existence test - a relatively expensive operation - when you know that a certain file exists. But it also means that if you have any doubt about the file's existence you must use the queries in the style
+{{caution|You will notice in the flat-short form that all these queries except the first have exists as a precondition. This precondition is good for efficiency since it saves an existence test - a relatively expensive operation - when you know that a certain file exists. But it also means that if you have any doubt about the file's existence you must use the queries in the style

- if my_file . exists and then my_file . is_readable then ... }} + if my_file.exists and then my_file.is_readable then ... }} FILE is a deferred class. Various implementations are possible. A quite detailed one is PLAIN_TEXT_FILE, which adds many features for accessing reading and writing data from/to a file.
[[ref:/libraries/base/reference/unix_file_info_chart|UNIX_FILE_INFO]] describes objects that contain internal information, such as protection mode and size, about a file.
@@ -427,7 +427,7 @@ The class also provides a set of constant integer-valued attributes which denote Another occasional requirement is for a mechanism to trigger an exception explicitly. Procedure raise answers this needs; the argument, a string, is the tag chosen for the exception. The code in this case is Developer_exception; the query is_developer_exception will return true; and the tag is accessible through feature tag_name.
You will notice in the interface specification for [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] that for some properties of the latest exception there are two features, one with a name such as exception or recipient_name as seen above and the other with a name prefixed by original_: original_exception, original_recipient_name. -{{warning| ''' CAUTION''': The reason for the presence of these pairs is that the immediately visible cause of a routine interruption may not be the real one. Assume that routine r from class C, which has a Rescue clause, calls s from D with no Rescue clause, and that some call executed by s causes a precondition violation. Because s has no Rescue clause of its own, s will fail. Up the call chain, the first routine that has a Rescue clause - r itself, or one of its own direct or indirect callers - may process the exception; but if it examines the exception code through attribute exception it will get the value of Routine_failure. This may be what you want; but to handle the situation in a finer way you will usually need to examine the code for the original exception, the one that interrupted s. This code will be accessible through the attribute original_exception, which in this case will have the value of Precondition, the exception code for precondition violations. So you have the choice between exploring the properties of the original exception, or those of the resulting routine failures. Just make sure you know what you are looking for. }} +{{caution|The reason for the presence of these pairs is that the immediately visible cause of a routine interruption may not be the real one. Assume that routine r from class C, which has a Rescue clause, calls s from D with no Rescue clause, and that some call executed by s causes a precondition violation. Because s has no Rescue clause of its own, s will fail. Up the call chain, the first routine that has a Rescue clause - r itself, or one of its own direct or indirect callers - may process the exception; but if it examines the exception code through attribute exception it will get the value of Routine_failure. This may be what you want; but to handle the situation in a finer way you will usually need to examine the code for the original exception, the one that interrupted s. This code will be accessible through the attribute original_exception, which in this case will have the value of Precondition, the exception code for precondition violations. So you have the choice between exploring the properties of the original exception, or those of the resulting routine failures. Just make sure you know what you are looking for. }} As you will see from the header comments in the flat-short form of class [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] , the queries that return detailed information about an exception, such as assertion_violation, all give an answer determined by original_exception rather than exception, since when the two are different (that is to say, when you handle the exception in a routine other than the original recipient) the value of exception is always Routine_failure and there is nothing more to say about it. @@ -444,7 +444,7 @@ Because signal codes are platform-dependent, the features of [[ref:/libraries/ba Class [[ref:/libraries/base/reference/memory_chart|MEMORY]] , like [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] , is meant to be used as an ancestor by classes that need its facilities. It offers a number of features for controlling memory management and fine-tuning the garbage collection mechanism, a key component of the Eiffel Software environment.
One of the most useful features in this class is dispose. This procedure describes actions to be applied to an unreachable object just before the garbage collector reclaims it. By default, as declared in [[ref:/libraries/base/reference/memory_chart|MEMORY]] , the procedure does nothing; but you may redefine it in a proper descendant of [[ref:/libraries/base/reference/memory_chart|MEMORY]] to describe dispose actions. Normally such actions will involve freeing external resources: for example a class describing file descriptors may redefine dispose so that whenever a descriptor object is garbage-collected the corresponding file will be closed. -{{warning| '''Caution''': This example is typical of proper uses of dispose.In a dispose procedure you should not include any instruction that could modify the Eiffel object structure, especially if some objects in that structure may themselves have become unreachable: these instructions could conflict with the garbage collector's operations and cause catastrophic behavior. The legitimate use of dispose redefinitions is for disposing of non-Eiffel resources. }} +{{caution|This example is typical of proper uses of dispose. In a dispose procedure you should not include any instruction that could modify the Eiffel object structure, especially if some objects in that structure may themselves have become unreachable: these instructions could conflict with the garbage collector's operations and cause catastrophic behavior. The legitimate use of dispose redefinitions is for disposing of non-Eiffel resources. }} Other features of [[ref:/libraries/base/reference/memory_chart|MEMORY]] provide direct control over the operation of the garbage collector. You can in particular stop garbage collection through a call to collection_off, and restart it through a call to collection_on. By default, garbage collection is always on (a testimony to its authors' trust in its efficiency). Garbage collection is normally incremental, so as not to disrupt the application in a perceptible way. To start a complete garbage collection mechanism - reclaiming all unused objects - call procedure full_collect. The remaining features of [[ref:/libraries/base/reference/memory_chart|MEMORY]] enable finer control of the collection mechanism and are useful in special cases only. You will even find a free procedure providing brave (and competent) developers with a mechanism for reclaiming individual objects manually.
MEM_INFO, the result type for query memory_statistics in [[ref:/libraries/base/reference/memory_chart|MEMORY]] , describes objects containing information collected about memory usage. The features of [[ref:/libraries/base/reference/gc_info_chart|GC_INFO]] provide statistics about the garbage collector's operation. diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki index b7f99575..72e29945 100644 --- a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki +++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki @@ -15,16 +15,16 @@ Two classes provide basic mathematical functions such as logarithms and trigonom Class [[ref:/libraries/base/reference/internal_chart|INTERNAL]] provides low-level access to internal object structures. It, too, is meant to be used as ancestor by classes needing its features.
Here are some of the most useful calls and what they yield, obj being an entity attached to an object O and i an integer: -* [[ref:/libraries/base/reference/internal_flatshort|class_name]] (obj): the name of the generator class for O. -* [[ref:/libraries/base/reference/internal_flatshort|dynamic_type ]] ( obj ) : the integer code for the type of O, where each type in a system is identified by a unique code. -* [[ref:/libraries/base/reference/internal_flatshort|field_count ]] ( obj ) : the number of fields in O. -* [[ref:/libraries/base/reference/internal_flatshort|physical_size ]] ( obj ) : the space occupied by O, in bytes. -* field_xx ( i, obj ) where xx is name or offset: name or offset of the i-th field of O. -* [[ref:/libraries/base/reference/internal_flatshort|field ]] ( i, obj ) : the value of the i-th field of , if a reference; declared of type ANY in the class. -* yy_field ( i, obj ) where yy is boolean, character, integer, real or double: the value of the i-th field of O, if of the corresponding type; each declared of the appropriate type in the class. -* [[ref:/libraries/base/reference/internal_flatshort|is_special ]] ( obj ) , a boolean query which indicates whether O is a special object (the sequence of values representing the elements of an array or the characters of a string). +* class_name (obj) : the name of the generator class for O. +* dynamic_type (obj) : the integer code for the type of O, where each type in a system is identified by a unique code. +* field_count (obj) : the number of fields in O. +* physical_size (obj) : the space occupied by O, in bytes. +* field_xx (i, obj) where xx is name or offset: name or offset of the i-th field of O. +* field (i, obj) : the value of the i-th field of , if a reference; declared of type ANY in the class. +* yy_field (i, obj) where yy is boolean, character, integer, real or double: the value of the i-th field of O, if of the corresponding type; each declared of the appropriate type in the class. +* is_special (obj) : a boolean query which indicates whether O is a special object (the sequence of values representing the elements of an array or the characters of a string). -{{warning| '''CAUTION:''' Only very special cases justify the use of this class. Unless you are writing the lowest level of an interface between an Eiffel application and external tools (such as a database management system), and this requires passing to those tools information about the internals of Eiffel objects, you almost certainly should not use [[ref:/libraries/base/reference/internal_chart|INTERNAL]] . }} +{{warning|Only very special cases justify the use of the class [[ref:/libraries/base/reference/internal_chart|INTERNAL]]. Unless you are writing the lowest level of an interface between an Eiffel application and external tools (such as a database management system), and this requires passing to those tools information about the internals of Eiffel objects, you almost certainly should not use [[ref:/libraries/base/reference/internal_chart|INTERNAL]] . }} diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki index 30818120..7a9ec1df 100644 --- a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki +++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki @@ -1,7 +1,7 @@ [[Property:title|Create an object]] [[Property:weight|1]] [[Property:uuid|b2ef8e81-a045-dce2-725f-c8db5ab1b6db]] -An EiffelBuild [[EiffelBuild Notation|object]] is a representation of a Vision2 component and its properties. +An EiffelBuild [[EiffelBuild Notation|object]] is a representation of an EiffelVision 2 component and its properties. To create a new instance of an object, [[EiffelBuild Notation|pick]] a type from the [[Type selector|type selector]] and [[EiffelBuild Notation|drop]] onto an existing [[EiffelBuild Notation|object]] (Accessible from the [[Layout constructor|layout constructor]] or [[Builder window|builder window]] ). You will only be able to complete the [[EiffelBuild Notation|drop]] if the targeted [[EiffelBuild Notation|object]] will accept a new object of the transported type. diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki index cde13423..4d7127fb 100644 --- a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki +++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki @@ -1,9 +1,5 @@ [[Property:title|EiffelBuild: Starting a project]] [[Property:weight|0]] [[Property:uuid|803e2034-dec3-340c-e68e-fdbaefac8a5a]] -* [[EiffelBuild: Creating a new project|Creating a new project]] -* [[Retrieving a project from a Build project file|Retrieving a project from a Build project file]] - - diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki index be55f673..6928a2ff 100644 --- a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki +++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki @@ -1,13 +1,5 @@ [[Property:title|EiffelBuild How To's]] [[Property:weight|0]] [[Property:uuid|1df547c8-ca5b-f014-5b4f-a39ecefaa746]] -* [[EiffelBuild: Starting a project|Starting a project]] -* [[Create an object|Create an object]] -* [[Delete an object|Delete an object]] -* [[Save a project|Save a project]] -* [[Reparent an Object|Reparent an object]] -* [[Import a project|Import a Project]] - - diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki index 57c5154d..1a9cefb4 100644 --- a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki +++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki @@ -1,11 +1,5 @@ [[Property:title|EiffelBuild: General interface description]] [[Property:weight|2]] [[Property:uuid|e16b365e-469e-e2ab-e955-7f4e81630fe3]] -* [[EiffelBuild window overview|EiffelBuild window overview]] -* [[Main toolbar|Main toolbars]] -* [[EiffelBuild: Key shortcuts|Key shortcuts]] -* [[Docking|Docking]] - - diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki index bd097de2..5742471d 100644 --- a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki +++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki @@ -61,7 +61,8 @@ The complete list of the icons in the toolbar is displayed below.
The screenshot at the top of this page shows all of the buttons enabled. As the state of the currently open project changes, the state of each of these buttons is updated to reflect this. For example, immediately after saving the project, the save button is disabled until the project is modified again. -'''Note''': It is not possible to customize the toolbar. + +{{note|It is not possible to customize the toolbar. }} diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki index 1631b876..144a85c6 100644 --- a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki +++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki @@ -11,11 +11,9 @@ The options available in this tab are as follows: * '''Attribute declarations''' ** '''Local''' - All attributes (corresponding to widgets and items generated by EiffelBuild) are declared as local variables. ** '''Attributes''' -- All attributes are declared as attributes of the class with the following export status: -** *** '''Exported''' - All attributes are exported to ANY. *** '''Export only named''' - Only those attributes that have been named are exported to ANY while unnaned attributes are not exported.. *** '''Export None''' - None of the attributes are exported. - ** '''Grouped''' - Should different objects of same type be declared individually, or grouped?
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki index 4ea18a98..2ac298a0 100644 --- a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki +++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki @@ -1,23 +1,5 @@ [[Property:title|EiffelBuild Reference]] [[Property:weight|1]] [[Property:uuid|15b53149-5a31-9a1a-e9ad-739174678064]] -* [[EiffelBuild Introduction|EiffelBuild Introduction]] -* [[EiffelBuild Notation|EiffelBuild Notation]] -* [[EiffelBuild: General interface description|General interface description]] -* [[Layout constructor|Layout constructor]] -* [[Type selector|Type selector]] -* [[Object editor|Object editor]] -* [[Display window|Display window]] -* [[Builder window|Builder window]] -* [[Component selector|Component selector]] -* [[Widget selector|Widget selector]] -* [[Component viewer|Component viewer]] -* [[History|History]] -* [[Constants|Constants]] -* [[EiffelBuild: Project settings window|Project settings]] -* [[EiffelBuild Preferences|Preferences]] -* [[EiffelBuild: Code Generation|Code generation]] - - - +EiffelBuild is the high-level interface builder by Eiffel Software which allows you to develop graphical user interface (GUI) applications simply and quickly. diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki index b30c1e24..8d3b4d45 100644 --- a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki +++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki @@ -3,8 +3,10 @@ [[Property:uuid|eb93c9bf-53b3-6718-5c30-d17133633c6f]] The layout constructor provides a view of the [[EiffelBuild Notation|objects]] you have defined in your system, in which the [[EiffelBuild Notation|objects]] may be manipulated. The root node of the tree is the object currently selected within the [[Widget selector|widget selector]] and objects may be added/moved within the displayed widget structure by picking and dropping the objects as required. For example, in the screenshot below, you could add another list to the vertical box, by picking a list from the [[Type selector|type selector]] and dropping it on the vertical box object. + [[Image:layout-constructor]] + Each item in the tree represents one object. The screenshot above represents the following [[EiffelVision Introduction|EiffelVision2]] interface definition - An EV_TITLED_WINDOW containing one child, of type EV_VERTICAL_BOX. Within the vertical box there is an EV_HORIZONTAL_BOX and an EV_LIST. The list is empty, but the horizontal box contains three different objects of type EV_BUTTON. {{note|The widget displayed as the root of the Layout Constructor is the currently selected object in the [[Widget selector|Widget Selector]] . To edit the contents of a different widget, select the widget you wish to manipulate from the [[Widget selector|widget selector]] .}} @@ -33,7 +35,11 @@ An [[EiffelBuild Notation|object]] contained in a system may be highlighted in ==Locked Objects== Objects that are instances of other objects are displayed as locked objects within the Layout Constructor as illustrated below: + + [[Image:layout-constructor-locked]] + + The object of type OK_CANCEL_BUTTONS is a locked instance of another object as illustrated by the locked icon displayed on top of it's type icon. As a locked object is simply an instance of another object, its internal structure may not be manipulated directly within the Layout Constructor. To change the structure of a locked object, you must directly change the object of which it is an instance. To add a locked object to your interface, simply pick the object that you wish to re-use from the [[Widget selector|widget selector]] and drop it into the desired parent object within the Layout Constructor. In this case, the instance of the OK_CANCEL_BUTTONS object is actually comprised of a number of widgets which may only be modified through manipulation of the original OK_CANCEL_BUTTONS_OBJECT. Changes made to this original object are then applied to all instances within your interface structures. diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki index a13f4317..b0b1a734 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki @@ -13,6 +13,3 @@ The EiffelVision 2 library includes the following interface clusters: To see differences between released versions of EiffelVision, click [[Revisions and Bug Fixes|Here]] - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki index 2bbcaab9..8ee38b55 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki @@ -1,19 +1,19 @@ [[Property:title|Kernel]] [[Property:weight|1]] [[Property:uuid|d830dc77-cd77-1f52-0e39-e0ec1cffa028]] -The kernel cluster contains classes that provide functionality that are common to most Windowed application. These classes are considered the core, or kernel of any Vision2 application. The most important of these classes is [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] . This is used to initialize the graphical toolkit and event loop of your Vision2 application. Kernel also includes classes such as [[ref:libraries/vision2/reference/ev_timeout_chart| EV_TIMEOUT]] that calls procedures (via agents) at a set interval, and [[ref:libraries/vision2/reference/ev_color_chart| EV_COLOR]] which is used for coloring widgets and items. To start programming with Vision2, you first have to correctly initialize [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] . +The kernel cluster contains classes that provide functionality that are common to most Windowed application. These classes are considered the core, or kernel of any EiffelVision2 application. The most important of these classes is [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] . This is used to initialize the graphical toolkit and event loop of your EiffelVision2 application. Kernel also includes classes such as [[ref:libraries/vision2/reference/ev_timeout_chart| EV_TIMEOUT]] that calls procedures (via agents) at a set interval, and [[ref:libraries/vision2/reference/ev_color_chart| EV_COLOR]] which is used for coloring widgets and items. To start programming with EiffelVision2, you first have to correctly initialize [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] . ==Launching your application with EV_APPLICATION - The heart of all Vision2 systems== -[[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is the basis for every Vision2 application and is considered the most important class in the library. It is responsible for initializing the underlying toolkit that is driving the windowing system on the platform that you decide to compile your system on. It also also where the main event loop that drives your application is executed. +[[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is the basis for every EiffelVision2 application and is considered the most important class in the library. It is responsible for initializing the underlying toolkit that is driving the windowing system on the platform that you decide to compile your system on. It also also where the main event loop that drives your application is executed. {{note|It is ''' not''' possible to create a Vision2 component unless an application exists (query [[ref:/libraries/vision2/reference/ev_environment_chart|EV_ENVIRONMENT]] ). }} -You may inherit [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] or use it as a client in order to create your vision2 application. A simple method of using EV_APPLICATION is as follows: +You may inherit [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] or use it as a client in order to create your EiffelVision2 application. A simple method of using EV_APPLICATION is as follows: # Create an instance of EV_APPLICATION. # Create one or more windows for your application. # Launch the application. -An example of a Vision2 application using inheritance from [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is shown below. +An example of an EiffelVision2 application using inheritance from [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is shown below. class HELLOWORLD_APP @@ -42,7 +42,7 @@ An example of a Vision2 application using inheritance from [[ref:libraries/visio end -This is the same Vision2 application but instead using [/libraries/vision2/reference/ev_application_chart.xml| EV_APPLICATION ] in a client/supplier relationship. +This is the same EiffelVision2 application but instead using [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] in a client/supplier relationship. class HELLOWORLD_APP @@ -53,7 +53,7 @@ This is the same Vision2 application but instead using [/libraries/visio feature make is - -- Create the Vision2 application with a helloworld window. + -- Create the EiffelVision2 application with a helloworld window. local app: EV_APPLICATION helloworld_window: EV_TITLED_WINDOW @@ -70,8 +70,8 @@ This is the same Vision2 application but instead using [/libraries/visio ==What does Launch actually do?== -In Vision2, to launch an application means to pass control to the underlying graphical toolkit. Simply creating an application does not launch it. An explicit call to launch is required for the event processing to begin. -{{note|A Vision2 system is event based. This means that you do not have control of the execution within a Vision2 system, but must respond appropriately to [[Events|events]] as they occur. Therefore, if you call launch on an [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] , the processing for the application will continue indefinitely unless you have provided a way to exit the application. It is essential to initialize your components correctly, so your application can be exited (call destroy on the application). }} +In EiffelVision2, to launch an application means to pass control to the underlying graphical toolkit. Simply creating an application does not launch it. An explicit call to launch is required for the event processing to begin. +{{note|An EiffelVision2 system is event based. This means that you do not have control of the execution within an EiffelVision2 system, but must respond appropriately to [[Events|events]] as they occur. Therefore, if you call launch on an [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] , the processing for the application will continue indefinitely unless you have provided a way to exit the application. It is essential to initialize your components correctly, so your application can be exited (call destroy on the application). }} ==Building your application skeleton== @@ -80,9 +80,5 @@ Now that you have a basic application skeleton set up you can now go about * [[Containers|Adding containers to your window(s), then place your created widgets in those containers.]] * [[Events|Add code to respond to user actions with agents and action sequences.]] -Once you have learnt the basics of GUI programming within Vision2, you are well on the way to creating powerful multi-platform applications. The Application Programming Interface (API) of Vision2 has been designed in a way to ensure that the library is as intuitive, consistent and stylistic as possible. Heavy reuse of components from EiffelBase has been one of the main reasons that made this possible. - - - - +Once you have learnt the basics of GUI programming within EiffelVision2, you are well on the way to creating powerful multi-platform applications. The Application Programming Interface (API) of EiffelVision2 has been designed in a way to ensure that the library is as intuitive, consistent and stylistic as possible. Heavy reuse of components from EiffelBase has been one of the main reasons that made this possible.