diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki index 36029c0a..b9600c20 100644 --- a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki +++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki @@ -1,7 +1,7 @@ [[Property:title|Using threads]] [[Property:weight|7]] [[Property:uuid|9f53d641-093a-38cb-50bb-568aaadfeb34]] -Eiffel supports multithreaded programs. The [[EiffelThread Library|thread library]] provides ways to handle threads safely inside an Eiffel program. Make sure you [[Adding a library|add]] it to your project if you want to use threads. +Eiffel supports multithreaded programs. The [[EiffelThread]] provides ways to handle threads safely inside an Eiffel program. Make sure you [[Adding a library|add]] it to your project if you want to use threads. To create a multithreaded program or library: * Open the [[Advanced Options|Project Settings]] dialog. diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki index 7ce18b99..14f90b37 100644 --- a/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki +++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki @@ -6,7 +6,7 @@ The first thing to do to start Eiffeling is to create a project. Most commands a When opening EiffelStudio, by default a dialog is popped up that proposes to create or open a project: [[Image:startup-dialog]] Under '''Create project''', several options are offered, which depend on the platform you are on. -* '''Basic application''' is the most basic new project that can be generated. It only includes the [[EiffelBase Library|base library]] and by default only creates the frame of the project. This is the ideal choice to start a textual (console) application, or to discover Eiffel. Indeed, the project is very light and includes only things that are essential in any project. It is available on all platforms. +* '''Basic application''' is the most basic new project that can be generated. It only includes the [[EiffelBase|base library]] and by default only creates the frame of the project. This is the ideal choice to start a textual (console) application, or to discover Eiffel. Indeed, the project is very light and includes only things that are essential in any project. It is available on all platforms. * '''.NET application''' has by default all essential components to start a project targeting the Microsoft .NET platform. Of course, it is only available on Windows, and only if you have chosen to install the .NET support during the installation. * '''Vision2 application''' creates a new project that includes the [[EiffelVision Introduction|Eiffel Vision2 library]] . This is the perfect choice to start a platform-independent graphic application, or even any graphic application, since EiffelVision2 is easier to use than platform-specific libraries. This option is available on all platforms. * '''WEL application''' generates a project using the [[WEL|Windows Eiffel Library(WEL)]] . This option is recommended for projects needing advanced Windows features, or Windows applications that are time-critical, since the graphic functionality provided by WEL is more efficient than the one provided by Vision2, which on the other hand provides a platform-independent abstract interface. This wizard is only available on Windows. diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki index f04ec765..da7ca51a 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki @@ -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: -{{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. }} +{{rule|name=Assertion Redeclaration|text=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): -{{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. }} +{{rule|name=Repeated Inheritance|text=
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. @@ -617,6 +617,7 @@ ta: TEACHING_ASSISTANT since the valid calls are of the form ta.faculty_account and ta.student_account , neither of them ambiguous; the call ta.computer_account would be invalid, since after the renamings class TEACHING_ASSISTANT has no feature of that name. The select only applies to a call up.computer_account + with up of type UNIVERSITY_PERSON , dynamically attached to an instance of TEACHING_ASSISTANT ; then the select resolves the ambiguity by causing the call to use the version from TEACHER . @@ -728,7 +729,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: -{{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. }} +{{rule|name=Covariance|text=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/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 3dec2845..c85bc14a 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 @@ -138,8 +138,8 @@ SEQUENCE is constructed with the full extent of the technique described in the d To the features of [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] principally adds features for adding, changing and removing items. A few procedures in particular serve to insert items at the end: * s .put ( v ) adds v at the end of a sequence s . -* extend and force, at the [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] level, do the same as put. -* s .append ( s1 ) adds to the end of s the items of s1 (another sequence), preserving their s1 order. +* extend and force, at the [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] level, do the same as put. +* s .append ( s1 ) adds to the end of s the items of s1 (another sequence), preserving their s1 order. Other procedures work on the current position: * s . remove removes the item at current position. @@ -170,7 +170,7 @@ By default, chains can only be extended at the end, through extendremove_left and remove_right remove an item at the left and right or the cursor position. * Procedures merge_left and merge_right are similar to put_left and put_right but insert another dynamic chain rather than a single item. As the word 'merge' suggests, the merged structure, passed as argument, does not survive the process; it is emptied of its items. To preserve it, perform a clone or copy before the merge operation. -The class also provides implementations of prune, prune_all and wipe_out from [[ref:libraries/base/reference/collection_chart]] . To make these implementations useful, it defines queries extendible and prunable so that they return the value true. +The class also provides implementations of prune, prune_all and wipe_out from [[ref:libraries/base/reference/collection_chart|COLLECTION]] . To make these implementations useful, it defines queries extendible and prunable so that they return the value true. =Lists And Circular Structures= @@ -227,6 +227,7 @@ would not work if lin is a non-empty circular structure: Using exhausted in lieu of off solves this problem. In class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] , exhausted is an attribute which is set to false by start and finish, and is set to true by forth when advancing from the last item to the first and by back when backing up from the first item to the last. So you should write the loop as from lin.start + some_optional_initializing_operation (lin) until lin.exhausted @@ -272,7 +273,7 @@ The instance of type [[ref:/libraries/base/reference/linked_list_chart|LINKED_LI my_list: LINKED_LIST [SOME_TYPE] will have as its run-time value (if not void) a reference to such an object, which is really a list header. The actual list content is given by the [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] instances, each of which contains a value of type SOME_TYPE and a reference to the next item, called right.
-Clearly, a header of type [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] [ SOME_TYPE ] will be associated with cells of type [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] [ SOME_TYPE ] .
+Clearly, a header of type LINKED_LIST [SOME_TYPE] will be associated with cells of type LINKABLE [SOME_TYPE].
Features such as active and first are used only for the implementation; they are not exported, and so you will not find them in the flat-short specifications, although the figures show them to illustrate the representation technique.
A similar implementation is used for two-way-linked structures such as two-way lists and two-way circular chains. [[Image:two-way-list|fig.4: Two way linked list]] 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 197d2640..aa5d9d1e 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 @@ -168,14 +168,14 @@ It is important to note that this optimization, if at all necessary, should at m ==Tuples== A new Kernel Library class is introduced: [[ref:/libraries/base/reference/tuple_chart|TUPLE]] .
-Alone among all classes, class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] has a variable number of generic parameters. [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [X], [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [X, Y], [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [X, Y, Z] and so on are all valid types, assuming valid types X, Y, Z and so on.
+Alone among all classes, class TUPLE has a variable number of generic parameters. TUPLE, TUPLE [X], TUPLE [X, Y], TUPLE [X, Y, Z] and so on are all valid types, assuming valid types X, Y, Z and so on.
Conformance rules: [CONF1] For n >= 0 TUPLE [U1, U2, ..., Un, Un+1] conforms to TUPLE [U1, U2, ..., Un] -(and hence to [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n] if each of the U i conforms to each of the T i for 1 <= i <= n.) +(and hence to TUPLE [T1, T2, ..., Tn] if each of the Ui conforms to each of the Ti for 1 <= i <= n.) In particular all tuple types conform to [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , with no parameter. [CONF2] @@ -184,7 +184,7 @@ In particular all tuple types conform to [[ref:/libraries/base/reference/tuple_c 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). }} +{{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 [T1, T2, ..., Tn] for any n (including 0, for which there is no generic parameter). }} {{note|CONF1 should be understood in terms of the underlying mathematical model.
@@ -192,7 +192,7 @@ Mathematically, TUPLE [T1, T2, ..., Tn] is the set TUPLE n of all partial functi 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.) -Semantics: an instance of [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n] is a tuple whose first element is an instance of T 1, the second element being an instance of T 2 etc. (The precise definition is the mathematical one given in note 1.) Note that there can be more than n elements to the tuple: for example a tuple with first element 5 and second element "FOO" is an instance of all of the following tuple types: [[ref:/libraries/base/reference/tuple_chart|TUPLE]] ; [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] ]; [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/string_8_chart|STRING]] ]. +Semantics: an instance of TUPLE [T1, T2, ..., Tn] is a tuple whose first element is an instance of T1, the second element being an instance of T2 etc. (The precise definition is the mathematical one given in note 1.) Note that there can be more than n elements to the tuple: for example a tuple with first element 5 and second element "FOO" is an instance of all of the following tuple types: TUPLE; TUPLE [INTEGER]; TUPLE [INTEGER, STRING]. It may seem restrictive at first to permit only one class, [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , to have an arbitrary number of actual generic parameters. Why not have a general mechanism for declaring any class C so that all of C [X], C [X, Y] etc. are valid? But in fact this is not really a restriction. To obtain this effect without any complicated language convention, just declare C as C [G -> TUPLE] @@ -208,42 +208,42 @@ so we have all the necessary flexibility.) ==Tuple expressions== -Let e 1, e 2, ..., e n be expressions of respective types T 1, T 2, ..., T n. Then the expression +Let e1, e2, ..., en be expressions of respective types T1, T2, ..., Tn. Then the expression -[e 1, e 2, ..., e n] +[e1, e2, ..., en] -denotes an instance of [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n], whose first element is e 1, the second element being e 2 etc.
+denotes an instance of TUPLE [T1, T2, ..., Tn], whose first element is e1, the second element being e2, etc.
Tuple expressions can be nested: whereas [1, 2, 3] -is a tuple with three elements (representing an instance of [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] ]), +is a tuple with three elements (representing an instance of TUPLE [INTEGER, INTEGER, INTEGER]), [1, [2, 3]] -is a tuple with two elements, the second one itself a tuple; the overall expression represents an instance of [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] ].
+is a tuple with two elements, the second one itself a tuple; the overall expression represents an instance of TUPLE [INTEGER, TUPLE [INTEGER, INTEGER]].
As a special case of tuple expression syntax, the delimiters [ and ] are replaced by parentheses for the tuple representing the actual argument list of a routine call (see section 4). ==Tuple features== The exact specification of class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] will be described in an addition to ELKS. The principal features are: * [[ref:/libraries/base/reference/tuple_chart|count]] (number of significant elements) -* [[ref:/libraries/base/reference/tuple_chart|item]] (i), with the obvious precondition: the i-th element, of type [[ref:/libraries/base/reference/any_chart]] (since the value of i is not known at compile time); also first, second, third, fourth and fifth, of the appropriate types. +* [[ref:/libraries/base/reference/tuple_chart|item]] (i), with the obvious precondition: the i-th element, of type [[ref:/libraries/base/reference/any_chart|ANY]] (since the value of i is not known at compile time); also first, second, third, fourth and fifth, of the appropriate types. * [[ref:/libraries/base/reference/tuple_chart|put]] (x, i), with the obvious precondition: replace i-th element with x. If argument x is not of the appropriate type T i there is no effect. * [[ref:/libraries/base/reference/tuple_chart|is_equal]] : redefined to consider only the first n elements, where n is the smaller length. Other features under consideration include: -* stripped (i): a tuple of type [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, T i-1, T i+1, ..., T n], derived from the current one by removing the i-th component, again with the obvious precondition. +* stripped (i): a tuple of type TUPLE [T1, T2, Ti-1, Ti+1, ..., Tn], derived from the current one by removing the i-th component, again with the obvious precondition. * wedged (x, i): a tuple with one more element, inserted at position i. * '''infix''' "+": tuple concatenation * '''infix''' "++": element concatenation; t ++ x is the same thing as t.wedged (x, t.count + 1). ==What have we gained?== -First we have solved the only case in the Eiffel language in which an expression has no precisely defined type: polymorphic manifest arrays. We don't have manifest arrays any more, but manifest tuples, with a precisely defined type. No incompatibility is introduced thanks to rule CONF2. The original syntax for manifest arrays, Result := <1, e 2, ..., e n>>, will continue to be supported.
-Second, we can define functions that return multiple results. This is a quite significant increase in expressive power. No common language has that. (You have to go to Lisp and functional languages.) Just define [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [...] as the result type; in the function, you will write things like +First we have solved the only case in the Eiffel language in which an expression has no precisely defined type: polymorphic manifest arrays. We don't have manifest arrays any more, but manifest tuples, with a precisely defined type. No incompatibility is introduced thanks to rule CONF2. The original syntax for manifest arrays, Result := <>, will continue to be supported.
+Second, we can define functions that return multiple results. This is a quite significant increase in expressive power. No common language has that. (You have to go to Lisp and functional languages.) Just define TUPLE [...] as the result type; in the function, you will write things like -Result := [e 1, e 2, ..., e n] +Result := [e1, e2, ..., en] Also, from a theoretical viewpoint, feature calls are simpler and more homogeneous: every feature takes exactly one tuple as argument and returns exactly one tuple as a result. (Either of these tuples may be empty: the first for a feature with no argument, the second for a procedure.) The syntax for a call becomes Feature Arguments @@ -284,10 +284,10 @@ The argument indicates the number of characters for the initial allocation. This The object attached at run-time to an entity such declared of type [[ref:/libraries/base/reference/string_8_chart|STRING]] is not the actual sequence of characters but a string descriptor, which contains a reference to the actual string contents. As a result, four assignment or assignment-like operations are possible: -* '''A1''' s1 := s -* '''A2''' s2 . share ( s ) -* '''A3''' s3 := clone ( s ) -* '''A4''' s4 . copy ( s ) +* '''A1''' s1 := s +* '''A2''' s2.share (s) +* '''A3''' s3 := clone (s) +* '''A4''' s4.copy (s) As illustrated below, ''' A1''' is a reference assignment: s1 will be attached to the same descriptor as s. ''' A2''' keeps the descriptors distinct, but make them refer to the same sequence of characters. ''' A3''' uses the redefinition of clone for class [[ref:/libraries/base/reference/string_8_chart|STRING]] : s3 will be attached to a new string, completely distinct from the string attached to s1 although made of identical characters. ''' A4''' has almost the same effect as '''A3''', but is only applicable if s4 was not void, and will override the existing descriptor rather than creating a new one. [[Image:strings]] @@ -367,7 +367,7 @@ Sometime you will be in a position where the schema of a class will have changed * attributes have been renamed * attributes type have changed -The storable mechanism allows you to retrieve the old version of the object only if it was saved using the independent_store facility. Each time you retrieve an object of a certain base class whose schema has changed, the feature correct_mismatch will be called. This feature is defined in [/libraries/base/reference/any_chart.xml|ANY] and by default will raise an exception. To handle the mismatch, you need to redefine correct_mismatch in the base class whose schema has been changed. For example in EiffelBase, [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE] has changed between version 5.1 and version 5.2 to use SPECIAL rather than [/libraries/base/reference/array_chart.xml|ARRAY]for its internal data storage. To retrieve a 5.1 version of [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE], you need to define correct_mismatch as following: +The storable mechanism allows you to retrieve the old version of the object only if it was saved using the independent_store facility. Each time you retrieve an object of a certain base class whose schema has changed, the feature correct_mismatch will be called. This feature is defined in [[ref:/libraries/base/reference/any_chart|ANY]] and by default will raise an exception. To handle the mismatch, you need to redefine correct_mismatch in the base class whose schema has been changed. For example in EiffelBase, [[ref:/libraries/base/reference/hash_table_chart|HASH_TABLE]] has changed between version 5.1 and version 5.2 to use SPECIAL rather than [[ref:/libraries/base/reference/array_chart|ARRAY]] for its internal data storage. To retrieve a 5.1 version of [[ref:/libraries/base/reference/hash_table_chart|HASH_TABLE]], you need to define correct_mismatch as following: correct_mismatch is -- Attempt to correct object mismatch during retrieve using `mismatch_information'. @@ -406,9 +406,9 @@ correct_mismatch is end -Note the use of mismatch_information, this is a once feature of [/libraries/base/reference/any_chart.xml|ANY] of type MISMATCH_INFORMATION which behaves like a [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE]. The keys of the table are the names of the attributes on which a mismatch occurred and the values are the corresponding object fields as they were originally stored. In this particular case of [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE] we know that the previous version was an [/libraries/base/reference/array_chart.xml|ARRAY], so we do an assignment attempt and if it succeeds we assign its area to the corresponding attribute of [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE]. +Note the use of mismatch_information, this is a once feature of [[ref:/libraries/base/reference/any_chart|ANY]] of type MISMATCH_INFORMATION which behaves like a [[ref:/libraries/base/reference/hash_table_chart|HASH_TABLE]]. The keys of the table are the names of the attributes on which a mismatch occurred and the values are the corresponding object fields as they were originally stored. In this particular case of [[ref:/libraries/base/reference/hash_table_chart|HASH_TABLE]] we know that the previous version was an [[ref:/libraries/base/reference/array_chart|ARRAY]], so we do an assignment attempt and if it succeeds we assign its area to the corresponding attribute of [[ref:/libraries/base/reference/hash_table_chart|HASH_TABLE]]. -If a class name changed, then you need to create an instance of CLASS_NAME_TRANSLATIONS, it behaves like a [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE] where the keys represent the old name, and the value the new name. This instance needs to be created before the call to retrieved. +If a class name changed, then you need to create an instance of CLASS_NAME_TRANSLATIONS, it behaves like a [[ref:/libraries/base/reference/hash_table_chart|HASH_TABLE]] where the keys represent the old name, and the value the new name. This instance needs to be created before the call to retrieved. =Access To Internal Properties= @@ -452,15 +452,11 @@ MEM_INFO, the result type for query memory_statistics in [[ref: ==Command-line arguments== Writing, assembling and compiling a system yields an executable command. The system's users will call that command with arguments. These are normally provided in textual form on the command line, as in -'''your_system''' arg1 arg2 arg3 +your_system arg1 arg2 arg3 although one may conceive of other ways of entering the command arguments, such as tabular or graphical form-filling. In any case the software must be able to access the values passed as command arguments.
-A language mechanism is available for that purpose: the Root Class rule indicates that the creation procedure of the root class may have a single argument (in the Eiffel sense of argument to a routine) of type [[ref:/libraries/base/reference/array_chart|ARRAY]] [[[ref:/libraries/base/reference/string_8_chart|STRING]] ] . The corresponding array of strings will be initialized at the beginning of the system's execution with the values entered as arguments to that execution of the command.
+A language mechanism is available for that purpose: the Root Class rule indicates that the creation procedure of the root class may have a single argument (in the Eiffel sense of argument to a routine) of type [[ref:/libraries/base/reference/array_chart|ARRAY]] [ [[ref:/libraries/base/reference/string_8_chart|STRING]] ] . The corresponding array of strings will be initialized at the beginning of the system's execution with the values entered as arguments to that execution of the command.
Although this facility suffices in many cases, it is not always convenient if you suddenly need to access the command arguments in a class that is far-away from the root. An alternative mechanism, class ARGUMENTS, is available. Once again, this is a class from which you should inherit if you need its facilities. It has just two exported features: * argument_count, a non-negative integer, is the number of command arguments. * argument (i), a string, is the i-th command argument. Here i must be between 0 and argument_count; the convention is that for i = 0 the result is the name of the command itself. - - - - diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki index fd24cf50..eaddf055 100644 --- a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki +++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki @@ -1,9 +1,9 @@ [[Property:title|Duration]] [[Property:weight|1]] [[Property:uuid|64672bd0-b696-0c39-1e30-5ac64aae4a99]] -TIME_DURATION, DATE_DURATION AND DATE_TIME_DURATION +TIME_DURATION, DATE_DURATION, and DATE_TIME_DURATION -The classes dealing with duration inherit DURATION, which inherits GROUP_ELEMENT and PART_COMPARABLE. An instance of TIME_DURATION, DATE_DURATION or DATE_TIME_DURATION is an element of a group, i.e. there is a zero and addition operations (infix +,infix -, prefix + and prefix -). Duration is used as an amount of time, without link to an origin. It may be added to the respective absolute notion (time + time_duration is possible, not time + date_time_duration nor date_time + time_duration...see classes TIME, DATE and DATE_TIME). +The classes dealing with duration inherit DURATION, which inherits GROUP_ELEMENT and PART_COMPARABLE. An instance of TIME_DURATION, DATE_DURATION, or DATE_TIME_DURATION is an element of a group, i.e. there is a zero and addition operations (infix +, infix -, prefix + and prefix -). Duration is used as an amount of time, without link to an origin. It may be added to the respective absolute notion (time + time_duration is possible, not time + date_time_duration nor date_time + time_duration...see classes TIME, DATE, and DATE_TIME). Attributes are allowed to take negative values or values which do not stand in the usual range (hour = -1, minute = 75, day = 40...). However, features are available in each class to convert instances into the usual format: functions canonical and to_canonical are present in each class. An instance is canonical (canonical = True) if its attributes stand into the usual range. For example, an instance of TIME_DURATION such as 12:-10:60 is not canonical. to_canonical will return 11:51:0. In DATE_DURATION and DATE_TIME_DURATION, these features are also present. diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki index db17ef4a..fbaa5e1a 100644 --- a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki +++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki @@ -13,7 +13,7 @@ It would have been possible to create intervals with references to date or time, ====Interval measurement==== -The measure of intervals is made by duration: the result is an instance of the class DURATION. However, as DURATION is the common parent of TIME_DURATION, DATE_DURATION and DATE_TIME_DURATION, it does not have many features available. Some features in class TIME, DATE, DATE_TIME return the same result and are more efficient to use. DURATION has to be use as the last solution. +The measure of intervals is made by duration: the result is an instance of the class DURATION. However, as DURATION is the common parent of TIME_DURATION, DATE_DURATION, and DATE_TIME_DURATION, it does not have many features available. Some features in class TIME, DATE, and DATE_TIME return the same result and are more efficient to use. DURATION has to be use as the last solution. ====Comparison==== diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki index 64e44d42..fbe3e6b6 100644 --- a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki +++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki @@ -12,7 +12,7 @@ Manipulation on second and fractional_second are in fact always made through fin Features dealing with fine_second and fractional_second are described here. ====Creation (common to TIME, TIME_DURATION)==== -* make_fine looks like make but it takes a DOUBLE for its third argument (instead of an INTEGER). fine_second is then set to this value. +* make_fine looks like make but it takes a DOUBLE for its third argument (instead of an INTEGER). fine_second is then set to this value. * make_by_fine_seconds looks like make_by_seconds but it takes a DOUBLE for argument (instead of an INTEGER). Comparison (common) There are no new features. The same ones are available since they are written to deal with precision. It is possible to compare two instances, one with precision and the other one without. ====Measurement and access==== diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki index 5be6a971..2cc744dd 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki @@ -1,16 +1,14 @@ [[Property:title|EiffelVision 2 Samples]] [[Property:weight|3]] [[Property:uuid|79c05bf8-367e-001d-0c13-f668e34fa5b0]] -Vision2 ships with a number of samples provided to demonstrate different aspects of the library. If you are a new vision2 user then it is suggested that you first compile and run the [[Widgets Sample|Widgets]] sample. This will demonstrate both the appearance and behavior of the available widgets. +Vision2 ships with a number of samples provided to demonstrate different aspects of the library. If you are a new vision2 user then it is suggested that you first compile and run the -The other samples provided are listed below: +* [[Widgets Sample|Widgets]] sample. Demonstrates both the appearance and behavior of the available widgets. + +Then explore other samples: * [[Accelerator Sample|Accelerator]] - Demonstrates the use of an [[ref:/libraries/vision2/reference/ev_accelerator_chart|EV_ACCELERATOR]] . * [[Cursor Sample|Cursor]] - Demonstrates how to modify the displayed [[ref:/libraries/vision2/reference/ev_cursor_chart|EV_CURSOR]] for an [[ref:/libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] . * [[Gauges Sample|Gauges]] - Demonstrates different types of [[ref:/libraries/vision2/reference/ev_gauge_chart|EV_GAUGE]] . * [[Standard_dialogs Sample|Standard_dialogs]] - Demonstrates different types of [[ref:/libraries/vision2/reference/ev_standard_dialog_chart|EV_STANDARD_DIALOG]] . * [[Viewport Sample|Viewport]] - Demonstrates [[ref:/libraries/vision2/reference/ev_viewport_chart|EV_VIEWPORT]] . - - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki index 92475fd9..cfed2620 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki @@ -142,10 +142,3 @@ The relative points also support rotation and scaling. These factors work just l The scaling factor is divided into a horizontal and vertical component. If the factor is 0.5, everything is displayed at half its size. The rotation factor is in radians. - - - - - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki index 0e0062d1..b1d97374 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki @@ -45,9 +45,3 @@ Below is a structure showing the Vision2 components and the items that they acce *** [[ref:libraries/vision2/reference/ev_dynamic_tree_item_chart|EV_DYNAMIC_TREE_ITEM]] *** [[ref:libraries/vision2/reference/ev_tree_item_chart|EV_TREE_ITEM]] - - - - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki index 0d635cb4..ad9a604f 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki @@ -19,7 +19,7 @@ A simple example of this is demonstrated here: As print takes an argument of type [[ref:/libraries/base/reference/string_8_chart|STRING_8]] , button2 becomes a valid target for the pebble contained in button1. Right clicking the mouse pointer over the '''source''' will start the transport, and right clicking with the mouse pointer over a valid '''target''' will end the transport. The transport can be canceled anytime with a simple left click, just as you would do in EiffelStudio. -{{note|When a transport completes, the '''pebble''' that was transported is passed as an argument to all features in the '''targets'''drop_actions whose argument type matches the '''pebble''' }} +{{note|When a transport completes, the '''pebble''' that was transported is passed as an argument to all features in the '''targets''' drop_actions whose argument type matches the '''pebble'''. }} ==Three different modes of transport== @@ -36,7 +36,3 @@ This mode can be set with set_target_menu_mode. Right clicking When mode_is_pick_and_drop or mode_is_drag_and_drop then the shape of the mouse cursor changes to reflect whether the current GUI component below the mouse accepts the pebble or not. Calling set_accept_cursor allows you to customize this cursor used to represent a valid '''target''' while calling set_deny_cursor allows you to customize the cursor used for non valid '''targets'''. - - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki index 23f0b25c..d9326e29 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki @@ -42,7 +42,3 @@ The following properties are also used within Vision2: * [[ref:libraries/vision2/reference/ev_textable_chart|EV_TEXTABLE]] * [[ref:libraries/vision2/reference/ev_tooltipable_chart|EV_TOOLTIPABLE]] - - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki index 0eeb7111..f7df9fe7 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki @@ -11,7 +11,3 @@ In a similar vein to constant classes, the two following classes are provided to * [[ref:libraries/vision2/reference/ev_stock_colors_chart|EV_STOCK_COLORS]] * [[ref:libraries/vision2/reference/ev_stock_pixmaps_chart|EV_STOCK_PIXMAPS]] - - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki index 5f61ee0e..866b9dbc 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki @@ -1,22 +1,22 @@ [[Property:title|Containers]] [[Property:weight|1]] [[Property:uuid|aa71e29d-f0e0-9eb2-a289-675d24aac927]] -All Vision2 containers inherit [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] +All EiffelVision 2 containers inherit [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] ==What is a container?== -A container is a Vision2 widget that may contain other widgets. Some containers such as [[ref:libraries/vision2/reference/ev_cell_chart|EV_CELL]] may only hold one widget while containers such as [[ref:libraries/vision2/reference/ev_box_chart|EV_BOX]] may hold multiple widgets. As a container is of type [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] , this means that a container may be placed within a container. Windows inherit from [[ref:libraries/vision2/reference/ev_cell_chart|EV_CELL]] and are therefore classed as containers also. +A container is a EiffelVision 2 widget that may contain other widgets. Some containers such as [[ref:libraries/vision2/reference/ev_cell_chart|EV_CELL]] may only hold one widget while containers such as [[ref:libraries/vision2/reference/ev_box_chart|EV_BOX]] may hold multiple widgets. As a container is of type [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] , this means that a container may be placed within a container. Windows inherit from [[ref:libraries/vision2/reference/ev_cell_chart|EV_CELL]] and are therefore classed as containers also. {{note|Containers may only contain other widgets. Items may only be placed in certain primitives. For example, an [[ref:libraries/vision2/reference/ev_list_item_chart| EV_LIST_ITEM]] may be contained in an [[ref:libraries/vision2/reference/ev_list_chart| EV_LIST]] . }} ==Inheritance from Base== -Wherever possible, Vision2 containers reuse the container structures provided by Base. This provides three main advantages: -# Familiarity for operations such as access, insertions and removals. Anybody who already uses [[EiffelBase Library|Base]] should find it easy to adapt to using Vision2 containers. +Wherever possible, EiffelVision 2 containers reuse the container structures provided by [[EiffelBase]]. This provides three main advantages: +# Familiarity for operations such as access, insertions and removals. Anybody who already uses [[EiffelBase]] should find it easy to adapt to using EiffelVision 2 containers. # The underlying structures used have been tried and tested for many years and their design has been proved to be robust and effective. -# It provides powerful methods of querying the contents. In the original Vision library, you needed to keep reference to widgets as you could not query the contents of a container. +# It provides powerful methods of querying the contents. In the original EiffelVision library, you needed to keep reference to widgets as you could not query the contents of a container. -For example, [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] inherits BOX and COLLECTION. Descendents of [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] such as [[ref:libraries/vision2/reference/ev_box_chart|EV_BOX]] may also inherit other structures from [[EiffelBase Library|Base]] . +For example, [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] inherits BOX and COLLECTION. Descendents of [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] such as [[ref:libraries/vision2/reference/ev_box_chart|EV_BOX]] may also inherit other structures from [[EiffelBase]] . ==Usage of Containers== @@ -41,7 +41,7 @@ A code example of adding widgets to a container is as follows: end -The mapping of a Vision2 container interface is very close to that of containers in Base, such as a linked list. +The mapping of a EiffelVision 2 container interface is very close to that of containers in [[EiffelBase]], such as a linked list. * To add a widget to a container call `extend'. * To remove a widget from the container call `prune'. * To empty a container call `wipe_out'. @@ -60,8 +60,3 @@ As [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] is of ty - - - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki index 93c216ee..a5d36615 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki @@ -28,6 +28,3 @@ A message dialog gives your application a standard way of displaying useful (or * [[ref:libraries/vision2/reference/ev_confirmation_dialog_chart|EV_CONFIRMATION_DIALOG]] -- Allows the user to confirm an action that has been requested. * [[ref:libraries/vision2/reference/ev_error_dialog_chart|EV_ERROR_DIALOG]] -- Allows an error message to be shown to the user. - - - diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki index f3d1e367..5175510d 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki @@ -46,6 +46,3 @@ Now that you can create a widget, you will need to actually make it usable to yo * Making the widget respond to user [[Events| events]] via the use of agents and action sequences. * Placing the widget inside a [[Containers| container]] widget (either a window or a child of a window) so it can be shown on screen. - - -