diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki index fe476a2c..1e832260 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki @@ -5,7 +5,7 @@ The best way to speed up a program is of course to improve the algorithms and da Try to keep the number of classes and objects in your system as low as possible to ensure maximum efficiency. This should never hinder the design of the system, though. -You can also use the functionality provided by the [[ref:/libraries/base/reference/memory_chart|MEMORY]] class to tweak the garbage collector behavior according to your needs. However, be careful with this, since providing erroneous parameters might lead to memory leaks, huge memory consumption, or on the contrary a dramatic slow down of the application. If you are not entirely sure what a parameter is for, avoid changing it. The default values should fit for most standard applications. +You can also use the functionality provided by the [[ref:libraries/base/reference/memory_chart|MEMORY]] class to tweak the garbage collector behavior according to your needs. However, be careful with this, since providing erroneous parameters might lead to memory leaks, huge memory consumption, or on the contrary a dramatic slow down of the application. If you are not entirely sure what a parameter is for, avoid changing it. The default values should fit for most standard applications. On top of that, EiffelStudio provides powerful optimizations, some being done automatically, others being configurable. To obtain a maximum efficiency, it is recommended to [[Generating executables|Finalize]] your program from scratch and without using precompiled libraries. diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki index 7318c247..c41cbc3c 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki @@ -1,9 +1,9 @@ [[Property:title|Handling exceptions]] [[Property:weight|4]] [[Property:uuid|43ce73b9-3ac4-4f71-34a3-f359a66d9082]] -It is possible to raise and catch exceptions in Eiffel. Catching exceptions is done by using the rescue keyword. The [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] class provides helper features to analyze the caught exception and handle it. +It is possible to raise and catch exceptions in Eiffel. Catching exceptions is done by using the rescue keyword. The [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] class provides helper features to analyze the caught exception and handle it. -The [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] class also provides ways to raise exception, via its feature [[ref:libraries/base/reference/exceptions_flatshort|raise]] . +The [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] class also provides ways to raise exception, via its feature [[ref:libraries/base/reference/exceptions_flatshort|raise]] . When an exception is raised while the application is being debugged, the application stops immediately and the debugger displays the context in which the exception occurred, whether or not the exception is rescued. diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki index 7603fad6..cb1c1a4b 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki @@ -18,7 +18,7 @@ By default the profiler will profile the entire program. However it is possible * You must [[Generating executables|recompile]] your project for the changes to take effect. It is also possible to dynamically start and stop the profiler in a program. To do this: -* Create an object of type [[ref:/libraries/base/reference/profiling_setting_chart|PROFILING_SETTING]] . +* Create an object of type [[ref:libraries/base/reference/profiling_setting_chart|PROFILING_SETTING]] . * Call [[ref:libraries/base/reference/profiling_setting_flatshort|start_profiling]] on this object to start the profiler. * Call [[ref:libraries/base/reference/profiling_setting_flatshort|stop_profiling]] on this object to stop the profiler. diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/tracing.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/tracing.wiki index 62275dd7..d0593467 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/tracing.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/tracing.wiki @@ -43,7 +43,7 @@ Last, here's the output when '''Trace''' is '''True''' for both the root cluster =Dynamic control= It is also possible to enable and disable the trace dynamically. To do this: -* Create an object of type [[ref:/libraries/base/reference/tracing_setting_chart|TRACING_SETTING]] . +* Create an object of type [[ref:libraries/base/reference/tracing_setting_chart|TRACING_SETTING]] . * Call [[ref:libraries/base/reference/tracing_setting_flatshort|enable_tracing]] on this object to start the trace. * Call [[ref:libraries/base/reference/tracing_setting_flatshort|disable_tracing]] on this object to stop the trace. diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki index 6b8d3c47..5a3beba0 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki @@ -4,7 +4,7 @@ In both trees of the [[Object tool|object tool]], objects are displayed. The values displayed for each object fall into two categories: the object's attributes (grouped under the '''attributes''' folder [[Image:feature-attribute-icon]] ) and its once routines (grouped under the '''once routines''' folder [[Image:feature-once-icon]] ). The following symbol scheme is used to categorize each item: -* [[Image:debugger-object-immediate-icon]] An attribute of a basic Eiffel type, such as [[ref:/libraries/base/reference/kernel/integer_chart.xml|INTEGER]] or [[ref:/libraries/base/reference/kernel/classic/double_chart.xml|DOUBLE]] +* [[Image:debugger-object-immediate-icon]] An attribute of a basic Eiffel type, such as [[ref:libraries/base/reference/kernel/integer_chart.xml|INTEGER]] or [[ref:libraries/base/reference/kernel/classic/double_chart.xml|DOUBLE]] * [[Image:debugger-object-eiffel-icon]] An attribute that is a reference to an object * [[Image:debugger-object-void-icon]] A Void reference * [[Image:debugger-object-expanded-icon]] An object that is expanded diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki index 9c1c9733..25bcc2b0 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki @@ -6,7 +6,7 @@ For virtually any object displayed in the Object tool, it is possible for the de In order to have the instances of a class display such a string in the object tool, make the class an heir to class DEBUG_OUTPUT. Then implement the feature debug_output to return the string to be displayed. At run-time, the debugger will automatically query this feature on all objects that define it, and then will display the results in the object tool and the [[Expression evaluation|evaluation tool]]. -{{sample|The numeric *_REF classes inherit (through class NUMERIC) from the class DEBUG_OUTPUT so that it is possible to see immediately the value of *_REF objects in the Object tool. The *_REF classes are reference versions of the basic Eiffel classes such as [[ref:/libraries/base/reference/kernel/integer_chart.xml|INTEGER]] and [[ref:/libraries/base/reference/kernel/classic/double_chart.xml|DOUBLE]]. So, without DEBUG_OUTPUT, if you wanted to see, for example, the value of the [[ref:/libraries/base/reference/kernel/integer_chart.xml|INTEGER]] associated with an instance of [[ref:/libraries/base/reference/kernel/integer_ref_chart.xml|INTEGER_REF]] displayed in the Object tool, you would have expand the reference first.}} +{{sample|The numeric *_REF classes inherit (through class NUMERIC) from the class DEBUG_OUTPUT so that it is possible to see immediately the value of *_REF objects in the Object tool. The *_REF classes are reference versions of the basic Eiffel classes such as [[ref:libraries/base/reference/kernel/integer_chart.xml|INTEGER]] and [[ref:libraries/base/reference/kernel/classic/double_chart.xml|DOUBLE]]. So, without DEBUG_OUTPUT, if you wanted to see, for example, the value of the [[ref:libraries/base/reference/kernel/integer_chart.xml|INTEGER]] associated with an instance of [[ref:libraries/base/reference/kernel/integer_ref_chart.xml|INTEGER_REF]] displayed in the Object tool, you would have expand the reference first.}} {{tip|If an object has a long string output or an output with carriage returns, for instance, pick-and-drop it to the expanded display command [[Image:debugger-expand-info-icon]] in the object tool. }} diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki index 236abb97..4db06109 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki @@ -17,7 +17,7 @@ When an exception occurs (for instance, an assertion violation), the object tool All objects can be expanded to see the values of their attributes. They are also pickable, so that it is possible to drop them onto the Object tool, an [[Expression evaluation|expression evaluator tool]] (also know as Watch tool), or an editor. -It is also possible to use the [[Set slice size command|set slice size command]] with [[ref:/libraries/base/reference/special_chart|SPECIAL]] objects or [[ref:/libraries/base/reference/native_array_chart|NATIVE_ARRAY]] (.NET) objects. +It is also possible to use the [[Set slice size command|set slice size command]] with [[ref:libraries/base/reference/special_chart|SPECIAL]] objects or [[ref:libraries/base/reference/native_array_chart|NATIVE_ARRAY]] (.NET) objects. diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki index ef306a43..4f913097 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki @@ -22,7 +22,7 @@ Depending the nature of the dropped object, you can view it with one or more of ** deep_physicial_size ** physical_size -{{note|The "string display" viewer is available for objects with a string representation, for instance objects whose types conform to [[ref:/libraries/base/reference/string_8_chart|STRING_8]] or conform to [[ref:/libraries/base/reference/debug_output_chart|DEBUG_OUTPUT]] (see [[Debug output|Debug Output]]. )}} +{{note|The "string display" viewer is available for objects with a string representation, for instance objects whose types conform to [[ref:libraries/base/reference/string_8_chart|STRING_8]] or conform to [[ref:libraries/base/reference/debug_output_chart|DEBUG_OUTPUT]] (see [[Debug output|Debug Output]]. )}} {{note|The "XML display" is available for objects eligible for "String display", and whose string representation has XML content. The viewer displays XML in a tree-enabled grid.}} diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki index 43580c7b..529d5b5b 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki @@ -1,7 +1,7 @@ [[Property:title|Set slice size command]] [[Property:weight|3]] [[Property:uuid|ce2469a3-cf00-554e-47bd-5e8b2fdbc783]] -Located in the object tool toolbar, this command [[Image:debugger-set-sizes-icon]] changes the display size of special objects (i.e. objects whose class is [[ref:/libraries/base/reference/special_chart|SPECIAL]] ). Because special objects may contain thousands of attributes, only the first fifty are displayed by default. If left-clicked, a dialog is popped up that sets the exploration indices of special objects that will be loaded in the future. +Located in the object tool toolbar, this command [[Image:debugger-set-sizes-icon]] changes the display size of special objects (i.e. objects whose class is [[ref:libraries/base/reference/special_chart|SPECIAL]] ). Because special objects may contain thousands of attributes, only the first fifty are displayed by default. If left-clicked, a dialog is popped up that sets the exploration indices of special objects that will be loaded in the future. This pop-up also shows the "Maximum displayed string size" in the grid ([[Object tool|object tool]], or the [[Expression evaluation|watch tools]]). diff --git a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki index 3caf0c62..f108144f 100644 --- a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki +++ b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki @@ -8,7 +8,7 @@ A container can be studied from three viewpoints: access, storage and traversal. * The '''storage''' criterion affects how the items are put together. For example some containers are finite, others potentially infinite; among finite structures, some are bounded, others unbounded. * The '''traversal''' criterion affects how, if in any way, the items of a container can be traversed. A traversal is a mechanism which makes it possible to examine each item of a container once, in a clearly specified order. For example some containers can be traversed sequentially, in one direction or two; tree structures lend themselves to preorder, postorder and breadth-first traversals. -For each of these criteria the Base library offers a single-inheritance hierarchy of deferred classes. The top of the access hierarchy is class [[ref:libraries/base/reference/collection_chart|COLLECTION]] ; the top of the storage hierarchy is class [[ref:/libraries/base/reference/box_chart|BOX]] ; the top of the traversal hierarchy is class [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] . These three classes are heirs of the most general class [[ref:libraries/base/reference/container_chart|CONTAINER]] . +For each of these criteria the Base library offers a single-inheritance hierarchy of deferred classes. The top of the access hierarchy is class [[ref:libraries/base/reference/collection_chart|COLLECTION]] ; the top of the storage hierarchy is class [[ref:libraries/base/reference/box_chart|BOX]] ; the top of the traversal hierarchy is class [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] . These three classes are heirs of the most general class [[ref:libraries/base/reference/container_chart|CONTAINER]] . diff --git a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki index 9cc2233b..f0ce8065 100644 --- a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki +++ b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki @@ -1,19 +1,19 @@ [[Property:title|EiffelBase Data Structures, Lists]] [[Property:weight|1]] [[Property:uuid|23f540e0-16d5-807c-30af-74d3416a5709]] -Many applications need sequential structures, also called linear structures, in particular lists and circular chains. Apart from three classes describing individual list cells, all the classes involved are descendants of class [[ref:/libraries/base/reference/linear_chart|LINEAR]] , one of the deferred classes describing general traversal properties and introduced in the chapter that described the general data structure taxonomy. More precisely, all but one of the classes of interest for the present discussion are descendants, direct or indirect, from a class called [[ref:/libraries/base/reference/chain_chart|CHAIN]] which describes general sequential structures possessing a cursor as well as insertion properties. The exception is class [[ref:/libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] , which describes infinite structures; all the others describe finite structures.
-[[ref:/libraries/base/reference/chain_chart|CHAIN]] is an heir of [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] , which describes a more general notion of sequence. [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] is a descendant of [[ref:/libraries/base/reference/linear_chart|LINEAR]] . There are two main categories of sequential structures: some, called circular chains, are cyclic; others, called lists, are not. Another distinction exists between dynamic structures, which may be extended at will, and fixed ones, which have a bounded capacity.
+Many applications need sequential structures, also called linear structures, in particular lists and circular chains. Apart from three classes describing individual list cells, all the classes involved are descendants of class [[ref:libraries/base/reference/linear_chart|LINEAR]] , one of the deferred classes describing general traversal properties and introduced in the chapter that described the general data structure taxonomy. More precisely, all but one of the classes of interest for the present discussion are descendants, direct or indirect, from a class called [[ref:libraries/base/reference/chain_chart|CHAIN]] which describes general sequential structures possessing a cursor as well as insertion properties. The exception is class [[ref:libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] , which describes infinite structures; all the others describe finite structures.
+[[ref:libraries/base/reference/chain_chart|CHAIN]] is an heir of [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] , which describes a more general notion of sequence. [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] is a descendant of [[ref:libraries/base/reference/linear_chart|LINEAR]] . There are two main categories of sequential structures: some, called circular chains, are cyclic; others, called lists, are not. Another distinction exists between dynamic structures, which may be extended at will, and fixed ones, which have a bounded capacity.
In all of the structures under review you may insert two or more occurrences of a given item in such a way that the occurrences are distinguishable. In other words, the structures are bags rather than just sets, although it is possible to use them to implement sets. =Higher Level Traversal Classes= -The list and chain classes are characterized, for their traversal properties, as being linear and, more precisely, bilinear. In the traversal hierarchy, the relevant deferred classes are [[ref:/libraries/base/reference/linear_chart|LINEAR]] and [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , introduced in the [[EiffelBase, Abstract Container Structures: The Taxonomy|discussion]] of the general taxonomy. +The list and chain classes are characterized, for their traversal properties, as being linear and, more precisely, bilinear. In the traversal hierarchy, the relevant deferred classes are [[ref:libraries/base/reference/linear_chart|LINEAR]] and [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , introduced in the [[EiffelBase, Abstract Container Structures: The Taxonomy|discussion]] of the general taxonomy. ==Linear structures== -[[ref:/libraries/base/reference/linear_chart|LINEAR]] describes sequential structures that may be traversed one way. It introduces in particular the following features, illustrated on the figure below: +[[ref:libraries/base/reference/linear_chart|LINEAR]] describes sequential structures that may be traversed one way. It introduces in particular the following features, illustrated on the figure below: * after, a boolean-valued query which determines whether you have moved past the last position (a more precise specification is given below). -* off, a boolean-valued query which is false if and only if there is no item at the current position; for [[ref:/libraries/base/reference/linear_chart|LINEAR]] this is the same as: +* off, a boolean-valued query which is false if and only if there is no item at the current position; for [[ref:libraries/base/reference/linear_chart|LINEAR]] this is the same as: is_empty and not after * item, a query which returns the item at the current position - provided of course there is one, as expressed by the precondition: @@ -32,11 +32,11 @@ The list and chain classes are characterized, for their traversal properties, as There is also a procedure search with one argument, which determines whether the value of that argument appears in the structure at or after the current position, and if not makes after become true. This procedure is internally used by the default implementation of the has function (the general membership test) for linear structures. Like has for all containers, search uses object or reference equality depending on the value set for object_comparison. -An invariant property of [[ref:/libraries/base/reference/linear_chart|LINEAR]] structures is that the current position may go off one step past the last item if any, but no further. The precondition of forth - not after - helps ensure this. The first item (if any) being at position 1, the maximum allowable position is count + 1, where count is the number of items. +An invariant property of [[ref:libraries/base/reference/linear_chart|LINEAR]] structures is that the current position may go off one step past the last item if any, but no further. The precondition of forth - not after - helps ensure this. The first item (if any) being at position 1, the maximum allowable position is count + 1, where count is the number of items. ==Bilinear structures== -[[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] describes linear structures which may be traversed both ways. It inherits from [[ref:/libraries/base/reference/linear_chart|LINEAR]] and extends it with two new features which ensure complete symmetry between the two directions of movement: +[[ref:libraries/base/reference/bilinear_chart|BILINEAR]] describes linear structures which may be traversed both ways. It inherits from [[ref:libraries/base/reference/linear_chart|LINEAR]] and extends it with two new features which ensure complete symmetry between the two directions of movement: * before, a boolean-valued query which determines whether you have moved to the left of the first position (a more precise specification is given below). * back, a command to move backward by one position; the precondition is not before. @@ -48,20 +48,20 @@ For bilinear structures the position can range between 0 (not just 1) and count ==Invariant properties for after, before and off== -The redefinition of off illustrates a general methodological advice about invariants: be careful about not over-constraining the invariant by including properties that may be made more general in descendants. It might have been tempting to include in [[ref:/libraries/base/reference/linear_chart|LINEAR]] an invariant clause of the form +The redefinition of off illustrates a general methodological advice about invariants: be careful about not over-constraining the invariant by including properties that may be made more general in descendants. It might have been tempting to include in [[ref:libraries/base/reference/linear_chart|LINEAR]] an invariant clause of the form off = is_empty or after This property, however, would be too constraining. More precisely, it is always true that the right-hand side implies the left-hand-side: if a linear structure is either empty or after, then it is off. But the converse is not true, since certain kinds of linear structure, for example bilinear ones, may be off but neither empty nor after.
-The actual invariant for class [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] is obtained in three stages. In class [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] the feature off is deferred and a basic property of that feature is expressed by the invariant clause +The actual invariant for class [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] is obtained in three stages. In class [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] the feature off is deferred and a basic property of that feature is expressed by the invariant clause empty_constraint:is_empty implies off -In [[ref:/libraries/base/reference/linear_chart|LINEAR]] , feature off is effected through an implementation which returns the value of the expression is_empty or after. The class adds an invariant clause which, however, says less than the implementation to leave some room for variation: +In [[ref:libraries/base/reference/linear_chart|LINEAR]] , feature off is effected through an implementation which returns the value of the expression is_empty or after. The class adds an invariant clause which, however, says less than the implementation to leave some room for variation: after_constraint:after implies off -Finally [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , an heir of [[ref:/libraries/base/reference/linear_chart|LINEAR]] , redefines off to return the value of the expression +Finally [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , an heir of [[ref:libraries/base/reference/linear_chart|LINEAR]] , redefines off to return the value of the expression before or after @@ -73,7 +73,7 @@ The new implementation of off after or before -would not guarantee the invariant clause inherited from [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] were it not for another clause introduced in [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] : +would not guarantee the invariant clause inherited from [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] were it not for another clause introduced in [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] : empty_property: is_empty implies (after or before ) @@ -81,7 +81,7 @@ which indicates that an empty bilinear structure must always be after not_both: not(after and before) -The flat-short form of [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] shows the complete reconstructed invariant: +The flat-short form of [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] shows the complete reconstructed invariant: not_both: not (after and before) empty_property: is_empty implies (after or before) @@ -104,13 +104,13 @@ For a more general form of this scheme, applicable to circular chains as well as end The value of lin.off is always true for an empty structure, so in this case the loop will, correctly, execute only its initialization actions if present.
-This is a very common pattern, which you will find in the library classes themselves (for example has is implemented in this way) and many application clients. The iterator classes corresponding to linear structures ([[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] ) turn this pattern and several related ones into actual reusable routines.
+This is a very common pattern, which you will find in the library classes themselves (for example has is implemented in this way) and many application clients. The iterator classes corresponding to linear structures ([[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] ) turn this pattern and several related ones into actual reusable routines.
For bilinear structures there is another traversal mechanism going backward rather than forward; it is the same as above except that finish replaces start and back replaces finish. The exit condition remains off since before, like after, implies off. ==A precise view of after and before== Getting the specification of after and before right, so that it will handle all cases properly, requires some care.
-For every one of the structures under discussion there is a notion of current position, which we may call the cursor position even though for the moment the cursor is a virtual notion only. (Actual cursor objects will come later when we combine [[ref:/libraries/base/reference/linear_chart|LINEAR]] , [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] and other classes from the traversal hierarchy with [[ref:/libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] and other classes from the collection hierarchy.) The informal definition is that after is true if and only if the cursor - in this informal sense of a fictitious marker signaling the current position - is one position after the last item, if any, and that before is true if and only if the cursor is one position before the first item. When the cursor is on any of the items, after and before are false; after holds when the cursor is to the right of the last item, and before when it is to the left of the first item. This leaves open the question of what conventions to take for an empty structure. If iteration schemes of the above type are to work, then after must be true for an empty structure. For a bilinear structure, however, we should have total symmetry between the two pairs of features +For every one of the structures under discussion there is a notion of current position, which we may call the cursor position even though for the moment the cursor is a virtual notion only. (Actual cursor objects will come later when we combine [[ref:libraries/base/reference/linear_chart|LINEAR]] , [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] and other classes from the traversal hierarchy with [[ref:libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] and other classes from the collection hierarchy.) The informal definition is that after is true if and only if the cursor - in this informal sense of a fictitious marker signaling the current position - is one position after the last item, if any, and that before is true if and only if the cursor is one position before the first item. When the cursor is on any of the items, after and before are false; after holds when the cursor is to the right of the last item, and before when it is to the left of the first item. This leaves open the question of what conventions to take for an empty structure. If iteration schemes of the above type are to work, then after must be true for an empty structure. For a bilinear structure, however, we should have total symmetry between the two pairs of features * start, forth, after. * finish, back, before. @@ -128,7 +128,7 @@ When a structure is created, some initializations will have to be made; the defa if after and not is_empty then... -The solution finally retained for the Base libraries uses a different technique, which has turned out to be preferable. The idea is to replace the conceptual picture by one in which there are always two fictitious sentinel items. The two sentinel items are only present conceptually. They are of course not taken into account for the computation of count and, although it is possible to conceive of an implementation which would actually reserve space for them (for example in an array representation), none of the implementations used in Base for the classes of this documentation and other descendants of [[ref:/libraries/base/reference/linear_chart|LINEAR]] do. The only purpose of the sentinels is to provide two valid theoretical cursor positions, which exist regardless of the number of actual (non-sentinel) items in the structure.
+The solution finally retained for the Base libraries uses a different technique, which has turned out to be preferable. The idea is to replace the conceptual picture by one in which there are always two fictitious sentinel items. The two sentinel items are only present conceptually. They are of course not taken into account for the computation of count and, although it is possible to conceive of an implementation which would actually reserve space for them (for example in an array representation), none of the implementations used in Base for the classes of this documentation and other descendants of [[ref:libraries/base/reference/linear_chart|LINEAR]] do. The only purpose of the sentinels is to provide two valid theoretical cursor positions, which exist regardless of the number of actual (non-sentinel) items in the structure.
The sentinel items always appear at positions 0 and count + 1; this property is true even if the structure is empty of items, in which case count is zero. As a result, the following properties are part of the invariant: 0 <= index @@ -151,22 +151,22 @@ Finally, the only way to make delicate design decisions is to express the issues =Sequences And Chains= -Still deferred, classes [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] and[[ref:/libraries/base/reference/chain_chart|CHAIN]] provide the basis for all list and chain classes, as well as for many trees and for dispensers.
-SEQUENCE is constructed with the full extent of the technique described in the discussion of the taxonomy: using multiple inheritance to combine one class each from the access, traversal and storage hierarchy. [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] indeed has three parents: -* [[ref:/libraries/base/reference/active_chart|ACTIVE]] gives the access properties. A sequence is an active structure with a notion of current item. Remember that active structures are a special case of bags. -* [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , as studied above, indicates that a sequence may be traversed both ways. -* FINITE, from the storage hierarchy, indicates that the class describes finite sequences. (A class [[ref:/libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] is also present, as described below.) +Still deferred, classes [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] and[[ref:libraries/base/reference/chain_chart|CHAIN]] provide the basis for all list and chain classes, as well as for many trees and for dispensers.
+SEQUENCE is constructed with the full extent of the technique described in the discussion of the taxonomy: using multiple inheritance to combine one class each from the access, traversal and storage hierarchy. [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] indeed has three parents: +* [[ref:libraries/base/reference/active_chart|ACTIVE]] gives the access properties. A sequence is an active structure with a notion of current item. Remember that active structures are a special case of bags. +* [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , as studied above, indicates that a sequence may be traversed both ways. +* FINITE, from the storage hierarchy, indicates that the class describes finite sequences. (A class [[ref:libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] is also present, as described below.) -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: +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. +* 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. * s.replace ( v ) replaces by v the item at current position. -SEQUENCE, however, does not provide a procedure to insert an item at the current position, since not all implementations of sequences support this possibility; you will find it in descendants of [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] seen below.
+SEQUENCE, however, does not provide a procedure to insert an item at the current position, since not all implementations of sequences support this possibility; you will find it in descendants of [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] seen below.
Yet another group of features are based on the first occurrence of a certain item, or on all occurrences: * s.prune ( v ) removes the first occurrence of v in s, if any. * s.prune_all ( v ) removes all occurrences of v. @@ -176,16 +176,16 @@ These procedures have various abstract preconditions: s .extendible for ad ==Chains== Chains are sequences with a few more properties: items may be accessed through their indices, and it is possible to define cursor objects attached to individual items.
-Class [[ref:/libraries/base/reference/chain_chart|CHAIN]] is an heir of [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] . It gets its access properties from [[ref:/libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] (which adds the notion of cursor to the features of [[ref:/libraries/base/reference/active_chart|ACTIVE]] , already present in [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] ) and is also an heir of [[ref:/libraries/base/reference/indexable_chart|INDEXABLE]] . This ancestry implies in particular the presence of the following features: -* cursor, from [[ref:/libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] , which makes it possible to keep a reference to an item of the structure. -* i_th and put_i_th from [[ref:/libraries/base/reference/table_chart|TABLE]] , via [[ref:/libraries/base/reference/indexable_chart|INDEXABLE]] , which make it possible to access and replace the value of an item given by its integer index. +Class [[ref:libraries/base/reference/chain_chart|CHAIN]] is an heir of [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] . It gets its access properties from [[ref:libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] (which adds the notion of cursor to the features of [[ref:libraries/base/reference/active_chart|ACTIVE]] , already present in [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] ) and is also an heir of [[ref:libraries/base/reference/indexable_chart|INDEXABLE]] . This ancestry implies in particular the presence of the following features: +* cursor, from [[ref:libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] , which makes it possible to keep a reference to an item of the structure. +* i_th and put_i_th from [[ref:libraries/base/reference/table_chart|TABLE]] , via [[ref:libraries/base/reference/indexable_chart|INDEXABLE]] , which make it possible to access and replace the value of an item given by its integer index. -These features were called item and put in [[ref:/libraries/base/reference/table_chart|TABLE]] , but are renamed here to remove the conflict with homonymous features from [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] .
-Procedure put for chains is the version obtained from [[ref:/libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] , which has the same effect as replace - replacing the value of the item at cursor position. The put procedure from [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] is renamed sequence_ put. This feature is not exported by [[ref:/libraries/base/reference/chain_chart|CHAIN]] , however, since its effect (adding an item at the end) may be obtained through the simpler name extend. +These features were called item and put in [[ref:libraries/base/reference/table_chart|TABLE]] , but are renamed here to remove the conflict with homonymous features from [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] .
+Procedure put for chains is the version obtained from [[ref:libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] , which has the same effect as replace - replacing the value of the item at cursor position. The put procedure from [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] is renamed sequence_ put. This feature is not exported by [[ref:libraries/base/reference/chain_chart|CHAIN]] , however, since its effect (adding an item at the end) may be obtained through the simpler name extend. ==Dynamic chains== -By default, chains can only be extended at the end, through extend and sequence_put. Of particular interest are those chains where clients can insert and remove items at any position. Such chains are said to be dynamic, and described by [[ref:/libraries/base/reference/chain_chart|CHAIN]] 's heir [[ref:/libraries/base/reference/dynamic_chain_chart|DYNAMIC_CHAIN]] . The new features are predictable: +By default, chains can only be extended at the end, through extend and sequence_put. Of particular interest are those chains where clients can insert and remove items at any position. Such chains are said to be dynamic, and described by [[ref:libraries/base/reference/chain_chart|CHAIN]] 's heir [[ref:libraries/base/reference/dynamic_chain_chart|DYNAMIC_CHAIN]] . The new features are predictable: * Procedure put_front adds an item before the first. (As noted, the procedures to add an item after the last are already available in chains.) * Procedures put_left and put_right add an item at the left and right of the cursor position. * Procedures remove_left and remove_right remove an item at the left and right or the cursor position. @@ -198,17 +198,17 @@ The class also provides implementations of prune, prune A chain is a finite sequential structure. This property means that items are arranged in a linear order and may be traversed from the first to the last. To do this you may use a loop of the form shown above, based on procedures start and forth.
This property leaves room for several variants. In particular chains may be straight or circular. * A straight chain, which from now on will be called a list, has a beginning and an end. -* A circular chain, as represented by class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] and its descendants, has a much more flexible notion of first item. It is organized so that every item has a successor. +* A circular chain, as represented by class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] and its descendants, has a much more flexible notion of first item. It is organized so that every item has a successor. This representation is conceptual only; in fact the implementations of circular chains found in the Base libraries are based on lists, implemented in one of the ways described below (in particular linked and arrayed).
The major originality of circular chains is that unless the structure is empty procedure forth is always applicable: it will cycle past the last item, coming back to the
-first. The symmetric property applies to back. The cyclic nature of forth and back for circular chains is expressed precisely by the assertions. The version of forth for class [[ref:/libraries/base/reference/chain_chart|CHAIN]] , which comes from [[ref:/libraries/base/reference/linear_chart|LINEAR]] , has precondition +first. The symmetric property applies to back. The cyclic nature of forth and back for circular chains is expressed precisely by the assertions. The version of forth for class [[ref:libraries/base/reference/chain_chart|CHAIN]] , which comes from [[ref:libraries/base/reference/linear_chart|LINEAR]] , has precondition not after Similarly, the precondition for back is not before -For lists, after becomes true when the cursor moves past the last item. For circular chains, however, after and before are never true except for an empty structure; this is expressed by the invariant clauses of class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] : +For lists, after becomes true when the cursor moves past the last item. For circular chains, however, after and before are never true except for an empty structure; this is expressed by the invariant clauses of class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] : not before For a non-empty circular chain, then, you can circle forever around the items, using forth or back. @@ -218,7 +218,7 @@ For a non-empty circular chain, then, you can circle forever around the items, u For a list, the first and last items are fixed, and correspond to specific places in the physical representation.
A circular chain also needs a notion of first item, if only to enable a client to initiate a traversal through procedure start. Similarly, there is a last item - the one just before the first in a cyclic traversal. (If the chain has just one item, it is both first and last.)
For circular chains, however, there is no reason why the first item should always remain the same. One of the benefits that clients may expect from the use of a circular
-structure is the ability to choose any item as the logical first. Class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] offers for that purpose the procedure set_start which designates the current cursor position as the first in the circular chain. Subsequent calls to start will move the cursor to this position; calls to finish will move the cursor to the cyclically preceding position. With most implementations, there will then be two notions of first position: the logical first, which clients may freely choose through calls to set_start; and the physical first, which results from the implementation. In a representation using an array with indices from 1 to capacity, for example, the physical first is position 1, and the logical first may be any index in the permitted range. In a linked representation, there will be a cell first element corresponding to the physical first, but the logical first is any cell in the chain.
+structure is the ability to choose any item as the logical first. Class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] offers for that purpose the procedure set_start which designates the current cursor position as the first in the circular chain. Subsequent calls to start will move the cursor to this position; calls to finish will move the cursor to the cyclically preceding position. With most implementations, there will then be two notions of first position: the logical first, which clients may freely choose through calls to set_start; and the physical first, which results from the implementation. In a representation using an array with indices from 1 to capacity, for example, the physical first is position 1, and the logical first may be any index in the permitted range. In a linked representation, there will be a cell first element corresponding to the physical first, but the logical first is any cell in the chain.
In such cases the circular chain classes have features called standard_first, standard_last, standard_start and so on, which are not exported (so that you will not see them in the flat-short forms) but serve to implement visible features such as first, last and forth. For example a possible implementation of forth for circular chains is forth is -- Move cursor to next item, cyclically. @@ -245,7 +245,7 @@ loop end would not work if lin is a non-empty circular structure: off would never become true, so that the loop would forever cycle over the structure's items. The same would apply to a loop using finish and back instead of start and forth. This behavior is the natural result of the semantics defined for off , forth and back for circular structures. But it prevents us from using these features to perform a single traversal which will visit every item once.
-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 +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 @@ -261,18 +261,18 @@ loop lin.forth end -This form is applicable to all linear structures, circular or not, since exhausted is introduced in class [[ref:/libraries/base/reference/linear_chart|LINEAR]] as a function which returns the same value as off .Its redefinition into an attribute, modified by start, finish, forth and back, does not occur until class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] .
-Because exhausted is more general than off , the iteration scheme just given (and its equivalent going backwards) is preferable to the earlier one using off , especially if there is any chance that the iteration might one day be applied to a lin structure that is circular. Classes of the Iteration library, in particular [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , rely on this scheme for iterating over linear structures. +This form is applicable to all linear structures, circular or not, since exhausted is introduced in class [[ref:libraries/base/reference/linear_chart|LINEAR]] as a function which returns the same value as off .Its redefinition into an attribute, modified by start, finish, forth and back, does not occur until class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] .
+Because exhausted is more general than off , the iteration scheme just given (and its equivalent going backwards) is preferable to the earlier one using off , especially if there is any chance that the iteration might one day be applied to a lin structure that is circular. Classes of the Iteration library, in particular [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , rely on this scheme for iterating over linear structures. ==Dynamic structures== For both lists and circular chains, the most flexible variants, said to be dynamic, allow insertions and deletions at any position.
-The corresponding classes are descendants of [[ref:/libraries/base/reference/dynamic_list_chart|DYNAMIC_LIST]] and [[ref:/libraries/base/reference/dynamic_circular_chart|DYNAMIC_CIRCULAR]] , themselves heirs of [[ref:/libraries/base/reference/dynamic_chain_chart|DYNAMIC_CHAIN]] studied above.
+The corresponding classes are descendants of [[ref:libraries/base/reference/dynamic_list_chart|DYNAMIC_LIST]] and [[ref:libraries/base/reference/dynamic_circular_chart|DYNAMIC_CIRCULAR]] , themselves heirs of [[ref:libraries/base/reference/dynamic_chain_chart|DYNAMIC_CHAIN]] studied above.
==Infinite sequences== -Class [[ref:/libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCES]] , built by inheritance from [[ref:/libraries/base/reference/countable_chart|COUNTABLE]] , [[ref:/libraries/base/reference/linear_chart|LINEAR]] and [[ref:/libraries/base/reference/active_chart|ACTIVE]] , is similar to [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] but describes infinite rather than finite sequences. +Class [[ref:libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCES]] , built by inheritance from [[ref:libraries/base/reference/countable_chart|COUNTABLE]] , [[ref:libraries/base/reference/linear_chart|LINEAR]] and [[ref:libraries/base/reference/active_chart|ACTIVE]] , is similar to [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] but describes infinite rather than finite sequences. =Implementations= @@ -285,22 +285,22 @@ as two categories with two subcategories each: * Linked implementations, which may be one-way or two-way. * Arrayed implementations, which may be resizable or fixed. -A linked implementation uses linked cells, each containing an item and a reference to the next cell. One-way structures are described by classes whose names begin with LINKED_, for example [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] . Two-way structures use cells which, in addition to the reference to the next cell, also include a reference to the previous one. Their names begin with TWO_WAY_.
+A linked implementation uses linked cells, each containing an item and a reference to the next cell. One-way structures are described by classes whose names begin with LINKED_, for example [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] . Two-way structures use cells which, in addition to the reference to the next cell, also include a reference to the previous one. Their names begin with TWO_WAY_.
An arrayed implementation uses an array to represent a linear structure. If the array is resizable, the corresponding class name begins with ARRAYED_, for example
-[[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] ; if not, the prefix is FIXED_. +[[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] ; if not, the prefix is FIXED_. ==Linked structures== -A linked structure requires two classes: one, such as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] , describes the list proper; the other, such as [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , describes the individual list cells. The figure should help understand the difference; it describes a linked list, but the implementation of linked circular chains is similar. +A linked structure requires two classes: one, such as [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] , describes the list proper; the other, such as [[ref:libraries/base/reference/linkable_chart|LINKABLE]] , describes the individual list cells. The figure should help understand the difference; it describes a linked list, but the implementation of linked circular chains is similar. [[Image:linked-list|fig.3: Linked list and linked cells]] -The instance of type [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] shown at the top contains general information about the list, such as the number of items (count) and a reference to the first element (first). Because lists are active structures with a notion of current position, there is also a reference active to the cell at the current position. An entity declared as +The instance of type [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] shown at the top contains general information about the list, such as the number of items (count) and a reference to the first element (first). Because lists are active structures with a notion of current position, there is also a reference active to the cell at the current position. An entity declared as 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.
+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 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. @@ -311,14 +311,14 @@ A similar implementation is used for two-way-linked structures such as two-way l ==Linked cells== -The classes describing list cells are descendants of a deferred class called [[ref:/libraries/base/reference/cell_chart|CELL]] , whose features are: +The classes describing list cells are descendants of a deferred class called [[ref:libraries/base/reference/cell_chart|CELL]] , whose features are: * item, the contents of the cell. * put ( v : like item ), which replaces the contents of the cell by a new value. -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. +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. -{{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 @@ -327,39 +327,39 @@ It may be implemented as Result := active.item end -using the item feature of [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , applied to active. +using the item feature of [[ref:libraries/base/reference/linkable_chart|LINKABLE]] , applied to active. ==One-way and two-way linked chains== -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.
+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. {{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. +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. ==Arrayed chains== -Arrayed structures as described by [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] and [[ref:/libraries/base/reference/arrayed_circular_chart|ARRAYED_CIRCULAR]] use arrays for their implementations. A list or circular chain of count items may be stored in positions 1 to count of an array of capacity items, where capacity >= count.
-An instance of [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] , as the name suggests, has a fixed number of items. In particular: -* Query extendible has value false for [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] : you may replace existing items, but not add any, even at the end. A [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] is created with a certain number of items and retains that number. -* As a result, [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] joins the deferred feature count of [[ref:/libraries/base/reference/list_chart|LIST]] with the feature count of ARRAY, which satisfies the property count = capacity. +Arrayed structures as described by [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] and [[ref:libraries/base/reference/arrayed_circular_chart|ARRAYED_CIRCULAR]] use arrays for their implementations. A list or circular chain of count items may be stored in positions 1 to count of an array of capacity items, where capacity >= count.
+An instance of [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] , as the name suggests, has a fixed number of items. In particular: +* Query extendible has value false for [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] : you may replace existing items, but not add any, even at the end. A [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] is created with a certain number of items and retains that number. +* As a result, [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] joins the deferred feature count of [[ref:libraries/base/reference/list_chart|LIST]] with the feature count of ARRAY, which satisfies the property count = capacity. * Query prunable has value false too: it is not possible to remove an item from a fixed list. -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.) +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.) -{{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. +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. ==Multi-arrayed lists== -For lists one more variant is available, combining some of the advantages of arrayed and linked implementations: [[ref:/libraries/base/reference/multi_array_list_chart|MULTI_ARRAY_LIST]] . With this implementation a list is
+For lists one more variant is available, combining some of the advantages of arrayed and linked implementations: [[ref:libraries/base/reference/multi_array_list_chart|MULTI_ARRAY_LIST]] . With this implementation a list is
divided into a number of blocks. Each block is an array, but the successive arrays are linked. =Sorted Linear Structures= -The class [[ref:/libraries/base/reference/comparable_struct_chart|COMPARABLE_STRUCT]] , an heir of [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , is declared as +The class [[ref:libraries/base/reference/comparable_struct_chart|COMPARABLE_STRUCT]] , an heir of [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , is declared as deferred class COMPARABLE_STRUCT [G -> COMPARABLE] inherit @@ -372,13 +372,13 @@ As indicated by the constrained generic parameter it describes bilinear structur {{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.
-The deferred class [[ref:/libraries/base/reference/part_sorted_list_chart|PART_SORTED_LIST]] describes lists whose items are kept ordered in a way that is compatible with a partial order relation defined on them. The class is declared as +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.
+The deferred class [[ref:libraries/base/reference/part_sorted_list_chart|PART_SORTED_LIST]] describes lists whose items are kept ordered in a way that is compatible with a partial order relation defined on them. The class is declared as deferred class PART_SORTED_LIST [G -> COMPARABLE]... -An implementation based on two-way linked lists is available through the effective heir [[ref:/libraries/base/reference/sorted_two_way_list_chart|SORTED_TWO_WAY_LIST]] .
-The deferred class [[ref:/libraries/base/reference/sorted_list_chart|SORTED_LIST]] , which inherits from [[ref:/libraries/base/reference/part_sorted_list_chart|PART_SORTED_LIST]] , assumes that the order relation on G is a total order. As a result, the class is able to introduce features min, max and median. Here too a two-way linked list implementation is available, through the effective class [[ref:/libraries/base/reference/sorted_two_way_list_chart|SORTED_TWO_WAY_LIST]] . +An implementation based on two-way linked lists is available through the effective heir [[ref:libraries/base/reference/sorted_two_way_list_chart|SORTED_TWO_WAY_LIST]] .
+The deferred class [[ref:libraries/base/reference/sorted_list_chart|SORTED_LIST]] , which inherits from [[ref:libraries/base/reference/part_sorted_list_chart|PART_SORTED_LIST]] , assumes that the order relation on G is a total order. As a result, the class is able to introduce features min, max and median. Here too a two-way linked list implementation is available, through the effective class [[ref:libraries/base/reference/sorted_two_way_list_chart|SORTED_TWO_WAY_LIST]] . diff --git a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki index 1ebeca76..71086065 100644 --- a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki +++ b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki @@ -3,7 +3,7 @@ [[Property:uuid|4f65d62b-940b-c3c2-557e-d709a2a1bcaf]] A dispenser is called that way because of the image of a vending machine (a dispenser) of a rather primitive nature, in which there is only one button. If you press the button and the dispenser is not empty, you get one of its items in the exit tray at the bottom, but you do not choose that item: the machine does. There is also an input slot at the top, into which you may deposit new items; but you have no control over the order in which successive button press operations will retrieve these items. -The deferred class [[ref:/libraries/base/reference/dispenser_chart|DISPENSER]] provides the facilities which will be shared by all specialized classes. In fact, the interface of all dispenser classes is nearly identical, with the exception of a few extra possibilities offered by priority queues. Many kinds of dispenser are possible, each defined by the relation that the machine defines between the order in which items are inserted and the order in which they arereturned. The Base libraries support three important categories - stacks, queues, and priority queues: +The deferred class [[ref:libraries/base/reference/dispenser_chart|DISPENSER]] provides the facilities which will be shared by all specialized classes. In fact, the interface of all dispenser classes is nearly identical, with the exception of a few extra possibilities offered by priority queues. Many kinds of dispenser are possible, each defined by the relation that the machine defines between the order in which items are inserted and the order in which they arereturned. The Base libraries support three important categories - stacks, queues, and priority queues: * A stack is a dispenser with a last-in, first-out (LIFO) internal policy: items come out in the reverse order of their insertion. Each button press returns the last deposited item. * A queue is a dispenser with a first-in, first-out (FIFO) internal policy: items come out in the order of their insertion. Each button press returns the oldest item deposited and not yet removed. * In a priority queue, items have an associated notion of order; the element that comes out at any given time is the largest of those which are in the dispenser. @@ -12,24 +12,24 @@ The deferred class [[ref:/libraries/base/reference/dispenser_chart|DISPENSER]] Stacks - dispensers with a LIFO retrieval policy - are a ubiquitous structure in software development. Their most famous application is to parsing (syntactic analysis), but many other types of systems use one or more stacks. Class STACK describes general stacks, without commitment to a representation. This is a deferred class which may not be directly instantiated. The fundamental operations are put (add an element at end of queue), item (retrieve the oldest element, non-destructively), remove (remove the oldest element), is_empty (test for empty queue).
Three effective heirs are provided: -* [[ref:/libraries/base/reference/linked_stack_chart|LINKED_STACK]] : stacks implemented as linked lists, with no limit on the number of items (count). -* [[ref:/libraries/base/reference/bounded_stack_chart|BOUNDED_STACK]] : stacks implemented as arrays. For such stacks, the maximum number of items (capacity) is set at creation time. -* [[ref:/libraries/base/reference/arrayed_stack_chart|ARRAYED_STACK]] : also implemented as arrays, but in this case there is no limit on the number of items; the interface is the same as [[ref:/libraries/base/reference/linked_stack_chart|LINKED_STACK]] except for the creation procedure. If the number of elements exceeds the initially allocated capacity, the array will simply be resized. +* [[ref:libraries/base/reference/linked_stack_chart|LINKED_STACK]] : stacks implemented as linked lists, with no limit on the number of items (count). +* [[ref:libraries/base/reference/bounded_stack_chart|BOUNDED_STACK]] : stacks implemented as arrays. For such stacks, the maximum number of items (capacity) is set at creation time. +* [[ref:libraries/base/reference/arrayed_stack_chart|ARRAYED_STACK]] : also implemented as arrays, but in this case there is no limit on the number of items; the interface is the same as [[ref:libraries/base/reference/linked_stack_chart|LINKED_STACK]] except for the creation procedure. If the number of elements exceeds the initially allocated capacity, the array will simply be resized. ==Queues== -Class [[ref:/libraries/base/reference/queue_chart|QUEUE]] describes general queues, without commitment to a representation. This is a deferred class which may not be directly instantiated. Three non-deferred heirs are also provided, distinguished by the same properties as their stack counterparts: -* [[ref:/libraries/base/reference/linked_queue_chart|LINKED_QUEUE]] -* [[ref:/libraries/base/reference/bounded_queue_chart|BOUNDED_QUEUE]] -* [[ref:/libraries/base/reference/arrayed_queue_chart|ARRAYED_QUEUE]] +Class [[ref:libraries/base/reference/queue_chart|QUEUE]] describes general queues, without commitment to a representation. This is a deferred class which may not be directly instantiated. Three non-deferred heirs are also provided, distinguished by the same properties as their stack counterparts: +* [[ref:libraries/base/reference/linked_queue_chart|LINKED_QUEUE]] +* [[ref:libraries/base/reference/bounded_queue_chart|BOUNDED_QUEUE]] +* [[ref:libraries/base/reference/arrayed_queue_chart|ARRAYED_QUEUE]] ==Priority Queues== -In a priority queue, each item has an associated priority value, and there is an order relation on these values. The item returned by item or removed by remove is the element with the highest priority.The most general class is [[ref:/libraries/base/reference/priority_queue_chart|PRIORITY_QUEUE]] , which is deferred. Two effective variants are provided: -* [[ref:/libraries/base/reference/linked_priority_queue_chart|LINKED_PRIORITY_QUEUE]] , a linked list implementation. -* [[ref:/libraries/base/reference/heap_priority_queue_chart|HEAP_PRIORITY_QUEUE]] which is more efficient and is to be preferred in most cases. A heap is organized like a binary tree, although physically stored in an array; elements with a high priority percolate towards the root. +In a priority queue, each item has an associated priority value, and there is an order relation on these values. The item returned by item or removed by remove is the element with the highest priority.The most general class is [[ref:libraries/base/reference/priority_queue_chart|PRIORITY_QUEUE]] , which is deferred. Two effective variants are provided: +* [[ref:libraries/base/reference/linked_priority_queue_chart|LINKED_PRIORITY_QUEUE]] , a linked list implementation. +* [[ref:libraries/base/reference/heap_priority_queue_chart|HEAP_PRIORITY_QUEUE]] which is more efficient and is to be preferred in most cases. A heap is organized like a binary tree, although physically stored in an array; elements with a high priority percolate towards the root. -Because it must be possible to compare priorities, the type of the items must conform to [[ref:/libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] . Constrained genericity ensures this; all the priority queue classes have a formal generic parameter constrained by [[ref:/libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] . +Because it must be possible to compare priorities, the type of the items must conform to [[ref:libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] . Constrained genericity ensures this; all the priority queue classes have a formal generic parameter constrained by [[ref:libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] . diff --git a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki index 300582cc..b81533ca 100644 --- a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki +++ b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki @@ -82,7 +82,7 @@ Here, given with its full implementation, is a typical Iteration library routine The precise form of the procedure in the class relies on a call to another procedure, until_continue, and on inherited assertions. Here everything has been unfolded for illustration purposes.
This procedure will traverse the linear structure identified by target and apply the procedure calledaction on every item up to but excluding the first one satisfying test.
The class similarly offers do_all, do_while, do_for, do_if and other procedures representing the common control structures. It also includes functions such as exists and forall, corresponding to the usual quantifiers.
-These iteration schemes depend on the procedure action, defining the action to be applied to successive elements, and on the function test, defining the boolean query to be applied to these elements. These features are declared in class [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] (the highest-level deferred class of the Iteration library); here is test: +These iteration schemes depend on the procedure action, defining the action to be applied to successive elements, and on the function test, defining the boolean query to be applied to these elements. These features are declared in class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] (the highest-level deferred class of the Iteration library); here is test: test: BOOLEAN -- Test to be applied to item at current position in @@ -96,12 +96,12 @@ These iteration schemes depend on the procedure action, definin not_off: not target.off end -This indicates that the value of the boolean function test will be obtained by applying item_test to the item at the current position in the target structure. In [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] , function item_test always return ; descendant classes will redefine it so as to describe the desired test. Similarly, action is declared in class [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] as a call to item_action. Descendants will redefine item_action, which as initially declared in [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] is a procedure with a null body.
+This indicates that the value of the boolean function test will be obtained by applying item_test to the item at the current position in the target structure. In [[ref:libraries/base/reference/iterator_chart|ITERATOR]] , function item_test always return ; descendant classes will redefine it so as to describe the desired test. Similarly, action is declared in class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] as a call to item_action. Descendants will redefine item_action, which as initially declared in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] is a procedure with a null body.
Going through item_action and item_test provides an extra degree of flexibility. Normally the action and test performed at each step apply to target . item>, so that it suffices to redefine the item_features. This is the case with all examples studied in this chapter. In a more general setting, however, you might need to redefine action and test themselves. ==An example use of iteration== -Here now is an example illustrating the use of these mechanisms. The result will enable us to resize all the paragraphs of a text up to the first one that has been modified - as we might need to do, in a text processing system, to process an interactive user request. Assume a class TEXT that describes lists of paragraphs with certain additional features. The example will also assume a class PARAGRAPH with a procedure resize, and a boolean-valued attribute modified which indicates whether a paragraph has been modified. Class TEXT inherits from [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] and so is a descendant of [[ref:/libraries/base/reference/linear_chart|LINEAR]] : +Here now is an example illustrating the use of these mechanisms. The result will enable us to resize all the paragraphs of a text up to the first one that has been modified - as we might need to do, in a text processing system, to process an interactive user request. Assume a class TEXT that describes lists of paragraphs with certain additional features. The example will also assume a class PARAGRAPH with a procedure resize, and a boolean-valued attribute modified which indicates whether a paragraph has been modified. Class TEXT inherits from [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] and so is a descendant of [[ref:libraries/base/reference/linear_chart|LINEAR]] : class TEXT @@ -151,7 +151,7 @@ feature {NONE} end Thanks to the iteration mechanism, the procedure resize_paragraphs simply needs two procedure calls: -* To set its argument t as the iteration target, it uses procedure set. (This procedure is from class [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] which passes it on to all iterator classes.) +* To set its argument t as the iteration target, it uses procedure set. (This procedure is from class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] which passes it on to all iterator classes.) * Then it simply calls until_do as defined above. Procedure item_action is redefined to describe the operation to be performed on each successive element. Function item_test is redefined to describe the exit test.
@@ -165,43 +165,43 @@ Let us now explore the classes of the Iteration library and the different ways o ==Overview of the classes== There are only four Iteration classes, whose simple inheritance structure appeared at the beginning of this chapter. -* [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] , a deferred class which describes the most general notion. -* [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , for iterating over linear structures and chains. -* [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] , a repeated heir of [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , for iterating in either direction over a bilinear structure. -* [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] , for iterating over trees. +* [[ref:libraries/base/reference/iterator_chart|ITERATOR]] , a deferred class which describes the most general notion. +* [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , for iterating over linear structures and chains. +* [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] , a repeated heir of [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , for iterating in either direction over a bilinear structure. +* [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] , for iterating over trees. -As you will remember from the [[EiffelBase, Abstract Container Structures: The Taxonomy|presentation]] of the abstract overall taxonomy, the traversal hierarchy describes how data structures can be traversed; its most general class is [[ref:/libraries/base/reference/two_way_list_chart|TRAVERSABLE]] .
+As you will remember from the [[EiffelBase, Abstract Container Structures: The Taxonomy|presentation]] of the abstract overall taxonomy, the traversal hierarchy describes how data structures can be traversed; its most general class is [[ref:libraries/base/reference/two_way_list_chart|TRAVERSABLE]] .
Each one of the iterator classes is paired with a traversal class (or two in one case): {| border="1" |- -| [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] -| [[ref:/libraries/base/reference/two_way_list_chart|TRAVERSABLE]] +| [[ref:libraries/base/reference/iterator_chart|ITERATOR]] +| [[ref:libraries/base/reference/two_way_list_chart|TRAVERSABLE]] |- -| [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] -| [[ref:/libraries/base/reference/linear_chart|LINEAR]] +| [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] +| [[ref:libraries/base/reference/linear_chart|LINEAR]] |- -| [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] -| [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] +| [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] +| [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] |- -| [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] -| [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] , [[ref:/libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] +| [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] +| [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] , [[ref:libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] |- -| [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] -| [[ref:/libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] +| [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] +| [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] |} Each iterator class relies on the corresponding traversal class to provide the features for traversing the corresponding data structures, such as start, forth, and exhausted for linear structures.
-Of course the data structure class used in connection with a given iterator class does not need to be the iterator's exact correspondent as given by the above table; it may be any one of its descendants. For example you may use [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] to iterate over data structures described not just by [[ref:/libraries/base/reference/linear_chart|LINEAR]] but also by such descendants as [[ref:/libraries/base/reference/list_chart|LIST]] , [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , or even [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] if you do not need the backward iteration features (for which you will have to use [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] ). +Of course the data structure class used in connection with a given iterator class does not need to be the iterator's exact correspondent as given by the above table; it may be any one of its descendants. For example you may use [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] to iterate over data structures described not just by [[ref:libraries/base/reference/linear_chart|LINEAR]] but also by such descendants as [[ref:libraries/base/reference/list_chart|LIST]] , [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , or even [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] if you do not need the backward iteration features (for which you will have to use [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] ). ==General iteration facilities== -Class [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] defines the features that apply to all forms of iterator.
-An iterator will always apply to a certain target structure. The target is introduced in [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] by the feature target: [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] [G]
-Both the iterator classes and the traversal classes are generic, with a formal generic parameter G. The actual generic parameters will be matched through the choice of iteration target: for a generic derivation of the form SOME_ITERATOR [ACTUAL_TYPE] the target can only be of type SOME_TRAVERSABLE [ACTUAL_TYPE] for the same ACTUAL_TYPE, where SOME_TRAVERSABLE is the traversal class matching SOME_ITERATOR according to the preceding table ([[ref:/libraries/base/reference/linear_chart|LINEAR]] for [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] and so on), or one of its proper descendants.
-Each of the proper descendants of [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] redefines the type of target to the matching proper descendant of [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] , to cover more specific variants of the iteration target, For example in [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] the feature is redefined to be of type [[ref:/libraries/base/reference/linear_chart|LINEAR]] . [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] also introduces the procedure for selecting a target: +Class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] defines the features that apply to all forms of iterator.
+An iterator will always apply to a certain target structure. The target is introduced in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] by the feature target: [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] [G]
+Both the iterator classes and the traversal classes are generic, with a formal generic parameter G. The actual generic parameters will be matched through the choice of iteration target: for a generic derivation of the form SOME_ITERATOR [ACTUAL_TYPE] the target can only be of type SOME_TRAVERSABLE [ACTUAL_TYPE] for the same ACTUAL_TYPE, where SOME_TRAVERSABLE is the traversal class matching SOME_ITERATOR according to the preceding table ([[ref:libraries/base/reference/linear_chart|LINEAR]] for [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] and so on), or one of its proper descendants.
+Each of the proper descendants of [[ref:libraries/base/reference/iterator_chart|ITERATOR]] redefines the type of target to the matching proper descendant of [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] , to cover more specific variants of the iteration target, For example in [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] the feature is redefined to be of type [[ref:libraries/base/reference/linear_chart|LINEAR]] . [[ref:libraries/base/reference/iterator_chart|ITERATOR]] also introduces the procedure for selecting a target: set (s: like target) -- Make s the new target of iterations. @@ -214,7 +214,7 @@ Each of the proper descendants of [[ref:/libraries/base/reference/iterator_chart target /= Void end -Next [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] introduces the routines describing the elementary action and test that will be applied to items of the iteration targets: +Next [[ref:libraries/base/reference/iterator_chart|ITERATOR]] introduces the routines describing the elementary action and test that will be applied to items of the iteration targets: action -- Action to be applied to item at current position in @@ -248,8 +248,8 @@ Next [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] introduces the r These routines rely on two others, item_action and item_test, which both take an argument of type G, the formal generic parameter. The reason, already noted above, is that in a vast majority of cases the iterated action and test solely depend, at each step of the traversal, on the item (of type G) at the current position. To define an iteration process, then, it suffices to redefine item_action and item_test in a descendant of the appropriate iteration class. Only in complex cases will it be necessary to redefine action and test themselves.
If you encounter such a case, note the caveat about action changing the target's structure. Understandably enough, an iterator that attempts to change the data structure while traversing it may engage in strange behavior. No such risk exists if you only redefine item_action, which may change the contents of items but not the structure itself.
-Another feature introduced in [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] is the query invariant_value, describing invariant properties that must be ensured at the beginning of any iteration and preserved by every iteration step. As declared in [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] this query always returns true, but proper descendants can redefine it to describe more interesting invariant properties.
-Finally, [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] introduces in deferred form the general iteration routines applicable to all iteration variants. They include two queries corresponding to the quantifiers of first-order predicate calculus: +Another feature introduced in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] is the query invariant_value, describing invariant properties that must be ensured at the beginning of any iteration and preserved by every iteration step. As declared in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] this query always returns true, but proper descendants can redefine it to describe more interesting invariant properties.
+Finally, [[ref:libraries/base/reference/iterator_chart|ITERATOR]] introduces in deferred form the general iteration routines applicable to all iteration variants. They include two queries corresponding to the quantifiers of first-order predicate calculus: * for_all will return true if all items of the target structure satisfy test. * exists will return true if at least one item satisfies test. @@ -260,12 +260,12 @@ The other routines are commands which will traverse the target structure and app * do_until, to all items up to and including the first one that satisfies test. * while_do and do_while, to all items up to the first one that does not satisfy test. (This can also be achieved with until_do or do_until by choosing the opposite test.) -All these features, and most of the other iteration features introduced in proper descendants of [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] and described next, have no argument. Information about the target of iteration comes from feature target, set by procedure set; information about what needs to be done for each item of the target structure comes from item_action and item_test. +All these features, and most of the other iteration features introduced in proper descendants of [[ref:libraries/base/reference/iterator_chart|ITERATOR]] and described next, have no argument. Information about the target of iteration comes from feature target, set by procedure set; information about what needs to be done for each item of the target structure comes from item_action and item_test. ==Linear and chain iteration== -[[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , an effective class, refines the iteration mechanisms for cases in which the target is a linear structure, such as a list in any implementation or a circular chain.
-The class effects all the deferred features inherited from [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] , taking advantage of the linear traversal mechanisms present in the corresponding traversal class, [[ref:/libraries/base/reference/linear_chart|LINEAR]] . Here for example is the effecting of do_if: +[[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , an effective class, refines the iteration mechanisms for cases in which the target is a linear structure, such as a list in any implementation or a circular chain.
+The class effects all the deferred features inherited from [[ref:libraries/base/reference/iterator_chart|ITERATOR]] , taking advantage of the linear traversal mechanisms present in the corresponding traversal class, [[ref:libraries/base/reference/linear_chart|LINEAR]] . Here for example is the effecting of do_if: do_if -- Apply action to every item of target satisfying @@ -285,7 +285,7 @@ The class effects all the deferred features inherited from [[ref:/libraries/base end end -This routine text relies on features start, forth and exhausted which, together with off, have for convenience been carried over to [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] from their counterparts in [[ref:/libraries/base/reference/linear_chart|LINEAR]] , with feature declarations such as +This routine text relies on features start, forth and exhausted which, together with off, have for convenience been carried over to [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] from their counterparts in [[ref:libraries/base/reference/linear_chart|LINEAR]] , with feature declarations such as off: BOOLEAN -- Is position of target off? @@ -296,18 +296,18 @@ This routine text relies on features start, forth and similarly for the others.
-In addition to effecting the general iteration features from [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] , class [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] introduces iteration features that apply to the specific case of linear structures: +In addition to effecting the general iteration features from [[ref:libraries/base/reference/iterator_chart|ITERATOR]] , class [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] introduces iteration features that apply to the specific case of linear structures: * search (b :BOOLEAN) moves the iteration to the first position satisfying test if b is true, or not satisfying test if b is false. This use of a boolean argument to switch between two opposite semantics is not part of the recommended style, and you will find few if any other examples in the Base libraries. Here, however, it was deemed preferable to the alternative, which would have involved four separate procedures (if together with search we consider continue_search discussed next). * With a linear structure we can implement an iteration corresponding to the 'for' loop of traditional programming languages, defined by three integers: the starting position, the number of items to be traversed, and the step between consecutive items. This is provided by procedure do_for ( starting , number , step :INTEGER). * Since with a linear target the iterator can advance the cursor step by step, the basic iteration operations are complemented by variants which pick up from the position reached by the last call: continue_until, until_continue, continue_while, while_continue, continue_search, continue_for. ==Two-way iteration== -Class [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] has all the features of [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , to which it adds features for iterating backward as well as forward.
+Class [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] has all the features of [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , to which it adds features for iterating backward as well as forward.
The class introduces commands finish and back, applying the corresponding operations to the two-way target. It also has a backward variant for every iteration feature. The name of each such variant is the name of the forward feature followed by ''_back'': do_all_back, until_do_back and so on.
An alternative design would have kept just one set of features and added two features: a command reverse to reverse the direction of future iteration operations, and a query backward to find out the direction currently in force.
-Contrary to what one might at first imagine, class [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] is extremely short and simple; its Feature clause only contains the declarations of two features, finish and back.
-The trick is to use repeated inheritance. [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] inherits twice from [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] ; the first inheritance branch yields the forward iteration features, the second yields those for backward iteration. There is no need for any explicit declaration or redeclaration of iteration features. Here is the entire class text that yields this result: +Contrary to what one might at first imagine, class [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] is extremely short and simple; its Feature clause only contains the declarations of two features, finish and back.
+The trick is to use repeated inheritance. [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] inherits twice from [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] ; the first inheritance branch yields the forward iteration features, the second yields those for backward iteration. There is no need for any explicit declaration or redeclaration of iteration features. Here is the entire class text that yields this result: class TWO_WAY_CHAIN_ITERATOR [G] @@ -379,13 +379,13 @@ This class provides a good example of the economy of expression that the full in ==Tree iteration== -Tree iterations, provided by class [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] , work on trees of the cursor tree form; only with this form of tree are traversal operations possible. Three forms of iteration are provided: preorder, postorder and breadth-first. They correspond to the three traversal policies described in the discussion of trees. Here too it would seem that a rather lengthy class is needed, but repeated inheritance works wonders.
-[[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] simply inherits three times from [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , renaming the features appropriately in each case: +Tree iterations, provided by class [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] , work on trees of the cursor tree form; only with this form of tree are traversal operations possible. Three forms of iteration are provided: preorder, postorder and breadth-first. They correspond to the three traversal policies described in the discussion of trees. Here too it would seem that a rather lengthy class is needed, but repeated inheritance works wonders.
+[[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] simply inherits three times from [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , renaming the features appropriately in each case: * pre_do_all, pre_until, and so on. * post_do_all, post_until, and so on. * breadth_do_all, breadth_until, and so on. -All it needs to do then is to redefine the type of target to be [[ref:/libraries/base/reference/cursor_tree_chart|CURSOR_TREE [G]]] , and to redefine six features: the three renamed start (pre_start, etc.) and the three forth ( pre_ forth, and so on). These seven redefinitions give us a full-fledged battery of tree iteration mechanisms. +All it needs to do then is to redefine the type of target to be [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE [G]]] , and to redefine six features: the three renamed start (pre_start, etc.) and the three forth ( pre_ forth, and so on). These seven redefinitions give us a full-fledged battery of tree iteration mechanisms. =Building and Using Iterators= @@ -394,14 +394,14 @@ An application class may use one of the iteration classes in either of two ways: ==The single descendant technique== -Assume an application class PROCESSOR that is a proper descendant of one of the effective iteration classes studied in this chapter. Then a routine of PROCESSOR, say iterate, may iterate a certain action over a data structure, subject to a certain test. First, class PROCESSOR must specify the action by redefining item_action and item_test (or, in the most general case, action and test). Then routine iterate must specify the target data structure through a call of the form set (t) where t represents the selected target data structure. The type of t must correspond to the iteration class selected as ancestor of PROCESSOR: for [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] it must be a descendant of [[ref:/libraries/base/reference/linear_chart|LINEAR]] (such as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , LINKED_CIRCULAR or any other list or circular chain classes); for [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] it must be a descendant of [[ref:/libraries/base/reference/linear_chart|BILINEAR]] such as [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] or [[ref:/libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] ; for [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] it must be a descendant of [[ref:/libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] . In all cases the actual generic parameters of the iterator class and ofthe data structure class must be compatible. Then the iteration proper is obtained simply by calling the appropriate procedure, without any qualification or arguments, for example: do_ if
+Assume an application class PROCESSOR that is a proper descendant of one of the effective iteration classes studied in this chapter. Then a routine of PROCESSOR, say iterate, may iterate a certain action over a data structure, subject to a certain test. First, class PROCESSOR must specify the action by redefining item_action and item_test (or, in the most general case, action and test). Then routine iterate must specify the target data structure through a call of the form set (t) where t represents the selected target data structure. The type of t must correspond to the iteration class selected as ancestor of PROCESSOR: for [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] it must be a descendant of [[ref:libraries/base/reference/linear_chart|LINEAR]] (such as [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , LINKED_CIRCULAR or any other list or circular chain classes); for [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] it must be a descendant of [[ref:libraries/base/reference/linear_chart|BILINEAR]] such as [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] or [[ref:libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] ; for [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] it must be a descendant of [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] . In all cases the actual generic parameters of the iterator class and ofthe data structure class must be compatible. Then the iteration proper is obtained simply by calling the appropriate procedure, without any qualification or arguments, for example: do_ if
It is hard to imagine a simpler scheme: no loops, no initialization, no arguments. Feature item_action may need to rely on some variable values. Because it does not take any argument, such values will have to be treated as attributes, with the corresponding set_... procedures to set and change their values. This also applies to the two schemes set next.
The single descendant technique has one drawback: it provides the iterating class, PROCESSOR, with only one set of iteration particulars. This limitation does not affect the number of targets: you may use as many targets as you wish, as long as they are of compatible types, by calling a routine such as iterate several times, or calling several such routines, each call being preceded by a call to set to define a new target. The limitation also does not affect the iterating scheme: one iteration could use do_if, the next do_all and so on. But it does require the action and test to be the same in all cases.
The next two techniques will remove this limitation. ==Using repeated inheritance== -One way to obtain several iteration schemes is a simple extension to the single descendant technique. You can use repeated inheritance to provide two or more variants. We have in fact already encountered the technique when studying how to derive [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] and [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] from [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] . The general pattern, applied here to just two iteration schemes but easily generalized to more, is straightforward: +One way to obtain several iteration schemes is a simple extension to the single descendant technique. You can use repeated inheritance to provide two or more variants. We have in fact already encountered the technique when studying how to derive [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] and [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] from [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] . The general pattern, applied here to just two iteration schemes but easily generalized to more, is straightforward: class DUAL_PROCESSOR diff --git a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki index 510bd6c8..56ce576d 100644 --- a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki +++ b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki @@ -27,16 +27,16 @@ With good implementations, however, it is possible to use hash tables with a per x := h.item (k) where h is a hash-table and k is a key (for example a string) as conceptually equivalent to the array operations mentioned above.
-The quality of a hashed implementation will depend both on the data structure that will store the objects, and on the choice of hashing function. Class [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] attempts to address the first concern; for the second, client developers will be responsible for choosing the proper hashing function, although Base provides a few predefined functions, in particular for class [[ref:/libraries/base/reference/string_8_chart|STRING]] . +The quality of a hashed implementation will depend both on the data structure that will store the objects, and on the choice of hashing function. Class [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] attempts to address the first concern; for the second, client developers will be responsible for choosing the proper hashing function, although Base provides a few predefined functions, in particular for class [[ref:libraries/base/reference/string_8_chart|STRING]] . ==When hash tables are appropriate== You may keep objects in a hash table if for each one of these objects you can find a key that uniquely identifies it. The objects and their keys may be of many possible kinds: * '''H1'''. In a simple example, the objects are integers; each integer serves as its own key. (More precisely we will use its absolute value, since it is convenient to have non-negative keys only.) This case is of more than theoretical interest, since it makes hash tables appropriate for storing a set of integers with widely scattered values, for which simple array storage would be a waste of space (see requirement '''A3''' above). -* '''H2'''. Frequently, the objects will be composite, that is to say, instances of a developer-defined class, and one of the attributes of that class, of type [[ref:/libraries/base/reference/string_8_chart|STRING]] , can serve as the key. For example if you were writing an Eiffel compiler you would probably need to keep a data structure that includes information about classes of the system. Each class is represented by an object with several fields describing the properties of the class; one of these fields, the class name, corresponding to an attribute of type [[ref:/libraries/base/reference/string_8_chart|STRING]] , will serve as key. +* '''H2'''. Frequently, the objects will be composite, that is to say, instances of a developer-defined class, and one of the attributes of that class, of type [[ref:libraries/base/reference/string_8_chart|STRING]] , can serve as the key. For example if you were writing an Eiffel compiler you would probably need to keep a data structure that includes information about classes of the system. Each class is represented by an object with several fields describing the properties of the class; one of these fields, the class name, corresponding to an attribute of type [[ref:libraries/base/reference/string_8_chart|STRING]] , will serve as key. * '''H3'''. Instead of being the full object (as in case '''H1''') or one of the object's fields (as in case '''H2'''), the key may have to be computed through a function of the generating class, which will take into account several attributes of the class (that is to say, for each object, several fields). -What this practically means is that in all cases you will need, in the generating class of the objects to be stored, a query (attribute or function) that gives the key. The type of the key is highly variable but must in all cases be a descendant of [[ref:/libraries/base/reference/hashable_chart|HASHABLE]] . This is true of both [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] (case '''H1''') and [[ref:/libraries/base/reference/string_8_chart|STRING]] (case '''H2'''). The requirements for being a [[ref:/libraries/base/reference/hashable_chart|HASHABLE]] are not harsh: all you need is a function hash_code that returns a non-negative integer.> +What this practically means is that in all cases you will need, in the generating class of the objects to be stored, a query (attribute or function) that gives the key. The type of the key is highly variable but must in all cases be a descendant of [[ref:libraries/base/reference/hashable_chart|HASHABLE]] . This is true of both [[ref:libraries/base/reference/integer_32_chart|INTEGER]] (case '''H1''') and [[ref:libraries/base/reference/string_8_chart|STRING]] (case '''H2'''). The requirements for being a [[ref:libraries/base/reference/hashable_chart|HASHABLE]] are not harsh: all you need is a function hash_code that returns a non-negative integer.> ==Using hash tables== diff --git a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki index 62f3715f..c3026832 100644 --- a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki +++ b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki @@ -34,7 +34,7 @@ This yields a simple definition of trees by multiple inheritance from [[ref:libr ===Dynamic recursive trees=== -An example of dynamic tree structure is provided by class [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] , an heir of both [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] and [[ref:libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] . There is also [[ref:libraries/base/reference/linked_tree_chart|LINKED_TREE]] , which inherits from [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] and [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , but [[ref:libraries/base/reference/two_way_tree_chart|TWO_WA Y_TREE]] is generally preferable since children of a node often needs to be traversed both ways; the notion of order is usually less significant here than for lists. Such a form of definition is a particularly effective way of conveying the profoundly recursive nature of trees. The corresponding classes are useful in many different areas such as graphics, text processing and compilation. To create a one-way or two-way linked tree, use +An example of dynamic tree structure is provided by class [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] , an heir of both [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] and [[ref:libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] . There is also [[ref:libraries/base/reference/linked_tree_chart|LINKED_TREE]] , which inherits from [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] and [[ref:libraries/base/reference/linkable_chart|LINKABLE]] , but [[ref:libraries/base/reference/two_way_tree_chart|TWO_WA Y_TREE]] is generally preferable since children of a node often needs to be traversed both ways; the notion of order is usually less significant here than for lists. Such a form of definition is a particularly effective way of conveying the profoundly recursive nature of trees. The corresponding classes are useful in many different areas such as graphics, text processing and compilation. To create a one-way or two-way linked tree, use create my_tree.make (root_value) This will attach my_tree to a new one-node tree, with root_value at the root node. Here my_tree must be declared of type [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] [MY_TYPE] for some type MY_TYPE, and root_value must be of type MY_TYPE.
@@ -100,7 +100,7 @@ Various procedures are available to move the cursor in all directions: * [[ref:libraries/base/reference/cursor_tree_chart|forth]] and [[ref:libraries/base/reference/cursor_tree_chart|back]] move the cursor forward and backward between siblings and can cause the cursor to end up [[ref:libraries/base/reference/cursor_tree_chart|after]] or [[ref:libraries/base/reference/cursor_tree_chart|before]] . * [[ref:libraries/base/reference/cursor_tree_chart|up]] moves the cursor up one level. The call may be made even when the cursor is [[ref:libraries/base/reference/cursor_tree_chart|after]] or [[ref:libraries/base/reference/cursor_tree_chart|before]] . If the cursor is on the root of the tree or below in an empty tree, the cursor ends up [[ref:libraries/base/reference/cursor_tree_chart|above]] . -You can move the cursor in any one direction ( [[ref:libraries/base/reference/cursor_tree_chart|up]] , [[ref:libraries/base/reference/cursor_tree_chart|down]] , [[ref:libraries/base/reference/cursor_tree_chart|forth]] , [[ref:libraries/base/reference/cursor_tree_chart|back]] ), repeatedly, until it is [[ref:libraries/base/reference/cursor_tree_chart|off]] ( [[ref:libraries/base/reference/cursor_tree_chart|above]] , [[ref:libraries/base/reference/cursor_tree_chart|below,]] [[ref:libraries/base/reference/cursor_tree_chart|after]] , [[ref:libraries/base/reference/cursor_tree_chart|before]] respectively), but once it is [[ref:libraries/base/reference/cursor_tree_chart|off]] , further movement in the same direction is prohibited. For example the precondition of [[ref:/libraries/base/reference/cursor_tree_chart|put_left]] requires [[ref:libraries/base/reference/cursor_tree_chart|before]] to be false, and the precondition of [[ref:/libraries/base/reference/cursor_tree_chart|put_right]] requires [[ref:libraries/base/reference/cursor_tree_chart|after]] to be false.
+You can move the cursor in any one direction ( [[ref:libraries/base/reference/cursor_tree_chart|up]] , [[ref:libraries/base/reference/cursor_tree_chart|down]] , [[ref:libraries/base/reference/cursor_tree_chart|forth]] , [[ref:libraries/base/reference/cursor_tree_chart|back]] ), repeatedly, until it is [[ref:libraries/base/reference/cursor_tree_chart|off]] ( [[ref:libraries/base/reference/cursor_tree_chart|above]] , [[ref:libraries/base/reference/cursor_tree_chart|below,]] [[ref:libraries/base/reference/cursor_tree_chart|after]] , [[ref:libraries/base/reference/cursor_tree_chart|before]] respectively), but once it is [[ref:libraries/base/reference/cursor_tree_chart|off]] , further movement in the same direction is prohibited. For example the precondition of [[ref:libraries/base/reference/cursor_tree_chart|put_left]] requires [[ref:libraries/base/reference/cursor_tree_chart|before]] to be false, and the precondition of [[ref:libraries/base/reference/cursor_tree_chart|put_right]] requires [[ref:libraries/base/reference/cursor_tree_chart|after]] to be false.
It is possible to move down from an [[ref:libraries/base/reference/cursor_tree_chart|above]] position; in an empty tree this brings the cursor [[ref:libraries/base/reference/cursor_tree_chart|below]] . Similarly, it is possible to move up from [[ref:libraries/base/reference/cursor_tree_chart|below]] , left from [[ref:libraries/base/reference/cursor_tree_chart|after]] , right from [[ref:libraries/base/reference/cursor_tree_chart|before]] .
The sentinel element above the tree's root is considered to be the root of a forest containing just one tree. This view justifies the convention for the result of arity when the cursor is above: 0 if the tree [[ref:libraries/base/reference/cursor_tree_chart|is_empty]] , 1 if it has a root (viewed as the child of the fictitious sentinel element). diff --git a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki index 72e29945..ce401540 100644 --- a/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki +++ b/documentation/trunk/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki @@ -5,15 +5,15 @@ The support cluster offers some commonly needed functionality that do not belong ==Conversions, mathematical properties and ASCII characters== -A few utility classes complement the [[EiffelBase, The Kernel|kernel]] facilities. [[ref:/libraries/base/reference/primes_chart|PRIMES]] , [[ref:/libraries/base/reference/random_chart|RANDOM]] and [[ref:/libraries/base/reference/fibonacci_chart|FIBONACCI]] are part of the data structure taxonomy; the others are meant to be used as ancestors by classes needing their features. +A few utility classes complement the [[EiffelBase, The Kernel|kernel]] facilities. [[ref:libraries/base/reference/primes_chart|PRIMES]] , [[ref:libraries/base/reference/random_chart|RANDOM]] and [[ref:libraries/base/reference/fibonacci_chart|FIBONACCI]] are part of the data structure taxonomy; the others are meant to be used as ancestors by classes needing their features. -Two classes provide basic mathematical functions such as logarithms and trigonometric functions: [[ref:/libraries/base/reference/single_math_chart|SINGLE_MATH]] for single precision and [[ref:/libraries/base/reference/double_math_chart|DOUBLE_MATH]] for the double-precision variants. [[ref:/libraries/base/reference/math_const_chart|MATH_CONST]] contains mathematical constants: p , the square root of two, Euler's constant e . +Two classes provide basic mathematical functions such as logarithms and trigonometric functions: [[ref:libraries/base/reference/single_math_chart|SINGLE_MATH]] for single precision and [[ref:libraries/base/reference/double_math_chart|DOUBLE_MATH]] for the double-precision variants. [[ref:libraries/base/reference/math_const_chart|MATH_CONST]] contains mathematical constants: p , the square root of two, Euler's constant e . -[[ref:/libraries/base/reference/primes_chart|PRIMES]] , [[ref:/libraries/base/reference/random_chart|RANDOM]] and [[ref:/libraries/base/reference/fibonacci_chart|FIBONACCI]] are data structure classes - heirs of [[ref:/libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] . In all of these classes function i_th takes an integer argument i and will return the i-th element of the sequence under consideration - prime numbers, pseudo-random numbers or Fibonacci numbers. These sequences are active structures, on which forth will advance the current position and item will return the value at the current position. A few other features are specific to each case: for example [[ref:/libraries/base/reference/random_flatshort|higher_prime]] will yield the smallest prime greater than or equal to a certain value, and [[ref:/libraries/base/reference/random_flatshort|set_seed]] will define the seed to be used for starting the pseudo-random sequence. +[[ref:libraries/base/reference/primes_chart|PRIMES]] , [[ref:libraries/base/reference/random_chart|RANDOM]] and [[ref:libraries/base/reference/fibonacci_chart|FIBONACCI]] are data structure classes - heirs of [[ref:libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] . In all of these classes function i_th takes an integer argument i and will return the i-th element of the sequence under consideration - prime numbers, pseudo-random numbers or Fibonacci numbers. These sequences are active structures, on which forth will advance the current position and item will return the value at the current position. A few other features are specific to each case: for example [[ref:libraries/base/reference/random_flatshort|higher_prime]] will yield the smallest prime greater than or equal to a certain value, and [[ref:libraries/base/reference/random_flatshort|set_seed]] will define the seed to be used for starting the pseudo-random sequence. ==Internal object structures== -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.
+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: * 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. @@ -24,7 +24,7 @@ Here are some of the most useful calls and what they yield, obj * 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|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]] . }} +{{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/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki index 8755b66d..94cc9e12 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki @@ -45,7 +45,7 @@ You can then access or modify [[ref:libraries/store/reference/db_table_flatshort end -{{note|to access attributes data with ''code'', you need to use the [[ref:/libraries/store/reference/db_table_description_flatshort|DB_TABLE_DESCRIPTION]] object associated to your [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] object. }} +{{note|to access attributes data with ''code'', you need to use the [[ref:libraries/store/reference/db_table_description_flatshort|DB_TABLE_DESCRIPTION]] object associated to your [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] object. }} ===2.3. Getting objects metadata=== diff --git a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki index b211f26b..8f7912a8 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki @@ -2,10 +2,10 @@ [[Property:weight|1]] [[Property:uuid|80cd0938-6837-3c17-8515-b4ac60a51d09]] Each interface class has an implementation counterpart that implements specific DBMS handling. The class prefix indicates clearly its layer, for instance: -* [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] is the interface to perform a database selection query. -* [[ref:/libraries/store/reference/database_selection_flatshort|DATABASE_SELECTION]] [ [[ref:/libraries/store/reference/database_flatshort|DATABASE]] ] is its implementation. +* [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] is the interface to perform a database selection query. +* [[ref:libraries/store/reference/database_selection_flatshort|DATABASE_SELECTION]] [ [[ref:libraries/store/reference/database_flatshort|DATABASE]] ] is its implementation. -The abstract [[ref:/libraries/store/reference/database_flatshort|DATABASE]] class represents a DBMS, i.e. it is the Eiffel-side database call interface. It is inherited for instance by the instantiable ORACLE and ODBC classes. +The abstract [[ref:libraries/store/reference/database_flatshort|DATABASE]] class represents a DBMS, i.e. it is the Eiffel-side database call interface. It is inherited for instance by the instantiable ORACLE and ODBC classes. EiffelStore enables to link common interface objects with database-specific implementation objects using a '''handle'''. This handle also enables to switch between different databases. diff --git a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki index 548772d1..e1d34268 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki @@ -1,11 +1,11 @@ [[Property:title|Data Modification]] [[Property:weight|1]] [[Property:uuid|ef5568ff-dc7c-4c85-0174-335fdab1bd84]] -Use the [[ref:/libraries/store/reference/db_change_flatshort|DB_CHANGE]] class to perform any operation on your database that does not require access to a result. You can for instance modify table row content, drop table rows, create and delete tables. +Use the [[ref:libraries/store/reference/db_change_flatshort|DB_CHANGE]] class to perform any operation on your database that does not require access to a result. You can for instance modify table row content, drop table rows, create and delete tables. {{note|Take a look at the [[Data Object Coupling|Data Storing]] capability if you want to '''insert''' table rows. }} -[[ref:/libraries/store/reference/db_change_flatshort|DB_CHANGE]] allows you to modify the database data using the SQL language: +[[ref:libraries/store/reference/db_change_flatshort|DB_CHANGE]] allows you to modify the database data using the SQL language: * Prepare your SQL query and use modify: modification: DB_CHANGE diff --git a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki index 5ed0161c..b6ec3bab 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki @@ -2,13 +2,13 @@ [[Property:weight|4]] [[Property:uuid|c51311cd-8782-0bc3-3ef7-000ea6eee37c]] A smart way to work with relational databases is to have Eiffel objects directly mapping relational tables. Three EiffelStore classes enable this coupling: -* [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] objects [[#describe|describe a relational table]] and allow Eiffel to create objects mapping database tables. -* [[ref:/libraries/store/reference/db_store_flatshort|DB_STORE]] works directly with [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] objects to [[#insert|insert data into relational tables]] . -* [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] can [[#map|map a database query result into Eiffel objects]] . +* [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] objects [[#describe|describe a relational table]] and allow Eiffel to create objects mapping database tables. +* [[ref:libraries/store/reference/db_store_flatshort|DB_STORE]] works directly with [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] objects to [[#insert|insert data into relational tables]] . +* [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] can [[#map|map a database query result into Eiffel objects]] . ==Describing relational tables with DB_REPOSITORY== -A [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] object stores available information about a table. To access this information, you mainly have to give the table name and load the table description: +A [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] object stores available information about a table. To access this information, you mainly have to give the table name and load the table description: repository: DB_REPOSITORY @@ -25,8 +25,8 @@ A [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] obje {{tip|Loading a table description is often a costly operation: table has to be fetched among existing tables then every table column description must be loaded. Hence it is better to store and reuse a repository (maybe with a HASH_TABLE) once it has been loaded. }} -Using the table information, [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] then helps generating Eiffel classes mapping relational tables: -* You can directly use {[[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] }.generate_class. Generated class may look like: +Using the table information, [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] then helps generating Eiffel classes mapping relational tables: +* You can directly use {[[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] }.generate_class. Generated class may look like: class CONTACTS @@ -50,10 +50,10 @@ feature -- Settings ==Inserting data in the database== -[[ref:/libraries/store/reference/db_store_flatshort|DB_STORE]] lets you easily insert rows into a table using: -* the table description provided by [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] . +[[ref:libraries/store/reference/db_store_flatshort|DB_STORE]] lets you easily insert rows into a table using: +* the table description provided by [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] . * a class mapping the relational table. -This is straight-forward since you only have to give [[ref:/libraries/store/reference/db_store_flatshort|DB_STORE]] the object filled with the table values. Suppose you want to add a contact into your database: +This is straight-forward since you only have to give [[ref:libraries/store/reference/db_store_flatshort|DB_STORE]] the object filled with the table values. Suppose you want to add a contact into your database: storage: DB_STORE contacts_rep: DB_REPOSITORY @@ -70,7 +70,7 @@ This is straight-forward since you only have to give [[ref:/libraries/store/refe ==Accessing database content with Eiffel objects== -[[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] lets you map data retrieved from the database into Eiffel objects: Result column names must match object attributes names so you can use for instance classes created by [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] . Class DB_ACTION redefines ACTION and can be used to retrieve Eiffel objects directly into an ARRAYED_LIST: +[[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] lets you map data retrieved from the database into Eiffel objects: Result column names must match object attributes names so you can use for instance classes created by [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] . Class DB_ACTION redefines ACTION and can be used to retrieve Eiffel objects directly into an ARRAYED_LIST: selection: DB_SELECTION list_filling: DB_ACTION [CONTACTS] @@ -89,7 +89,7 @@ This is straight-forward since you only have to give [[ref:/libraries/store/refe -{{note|You can see how actions are used in [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] . }} +{{note|You can see how actions are used in [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] . }}
{{seealso|
diff --git a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki index dff39620..388d2f6d 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki @@ -1,7 +1,7 @@ [[Property:title|Database control]] [[Property:weight|7]] [[Property:uuid|432c6e51-36d5-b469-c924-eb821713256a]] -Use the [[ref:/libraries/store/reference/db_control_flatshort|DB_CONTROL]] class to check or change database status and behavior. The main operations you are likely to use are: +Use the [[ref:libraries/store/reference/db_control_flatshort|DB_CONTROL]] class to check or change database status and behavior. The main operations you are likely to use are: * Handling database errors. * Connecting to the database. * Committing changes in the database. @@ -10,7 +10,7 @@ Use the [[ref:/libraries/store/reference/db_control_flatshort|DB_CONTROL]] clas Every EiffelStore interface class has an is_ok feature. This enables to check directly if the last database operation has been successful. -When an error is detected, you can use [[ref:/libraries/store/reference/db_control_flatshort|DB_CONTROL]] to obtain further information about the error: +When an error is detected, you can use [[ref:libraries/store/reference/db_control_flatshort|DB_CONTROL]] to obtain further information about the error: * error_message provides a description of the error that occurred. * error_code returns a code corresponding to the error type. This code enables to handle specific errors within your code without parsing the error_message. * warning_message provides a warning message about the last transaction performed. @@ -19,7 +19,7 @@ Once you have handled your error, for instance by displaying the error_message o ==Managing database connection== -[[ref:/libraries/store/reference/db_control_flatshort|DB_CONTROL]] lets you connect, check your connection, and disconnect from the database. +[[ref:libraries/store/reference/db_control_flatshort|DB_CONTROL]] lets you connect, check your connection, and disconnect from the database. The following example sum up these capabilities: diff --git a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki index 5b1f10e4..2421cfcf 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki @@ -1,11 +1,11 @@ [[Property:title|Database Selection]] [[Property:weight|2]] [[Property:uuid|de759a74-b3e1-c937-e620-67526c116925]] -Use the [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class to select data from the database. Once you have selected the data, you can [[Selection Access|access]] it with convenience using adaptative EiffelStore structures. +Use the [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class to select data from the database. Once you have selected the data, you can [[Selection Access|access]] it with convenience using adaptative EiffelStore structures. {{note|Take a look at the [[Data Object Coupling|Database/Eiffel objects Coupling]] if you need information about your database structure. }} -[[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] enables your application to get database content using SQL 'select' queries: +[[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] enables your application to get database content using SQL 'select' queries: * You can carry out 'select' queries in an intuitive way using directly the SQL language: selection: DB_SELECTION diff --git a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki index da9d8559..f63b2a27 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki @@ -3,7 +3,7 @@ [[Property:uuid|37222a07-a8f8-e57d-45f0-3b28cd66d660]] If you have to execute database queries which only differ in the expression values, you can create a template query and then bind variables into this template for each execution. -This mechanism can be applied for requests with a result ([[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] ) or without ([[ref:/libraries/store/reference/db_change_chart|DB_CHANGE]] ). Hence both classes inherits from STRING_HDL that actually handle variable binding. +This mechanism can be applied for requests with a result ([[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] ) or without ([[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] ). Hence both classes inherits from STRING_HDL that actually handle variable binding. To use variable binding: * [[#create|Create]] a template query. @@ -24,7 +24,7 @@ Variables syntax is simple: the ':' special character followed by the variable n selection.set_query ("Select * from CONTACTS where Firstname = ':" + Bind_var + "'") -{{note|The code example shows how to bind variables to a [[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] object but the mechanism is exactly the same for [[ref:/libraries/store/reference/db_change_chart|DB_CHANGE]] objects. }} +{{note|The code example shows how to bind variables to a [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] object but the mechanism is exactly the same for [[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] objects. }} ==Binding variables to a query== diff --git a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki index 50a99f7e..ea20f447 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki @@ -12,8 +12,8 @@ To use DB_RESULT, process in 2 steps: ==Retrieving DB_RESULT objects== -[[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class provides different ways to customize result loading: -* You want to access an '''unique''' row: [[ref:/libraries/store/reference/db_result_flatshort|DB_RESULT]] object is accessible via cursor: +[[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class provides different ways to customize result loading: +* You want to access an '''unique''' row: [[ref:libraries/store/reference/db_result_flatshort|DB_RESULT]] object is accessible via cursor: selection: DB_SELECTION my_result: DB_RESULT @@ -27,7 +27,7 @@ To use DB_RESULT, process in 2 steps: end -* You want to load a '''complete list''' of rows: [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] can store [[ref:/libraries/store/reference/db_result_flatshort|DB_RESULT]] objects in a list. To do this, you have mainly to provide a LIST object to DB_SELECTION with set_container: +* You want to load a '''complete list''' of rows: [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] can store [[ref:libraries/store/reference/db_result_flatshort|DB_RESULT]] objects in a list. To do this, you have mainly to provide a LIST object to DB_SELECTION with set_container: selection: DB_SELECTION container: ARRAYED_LIST [DB_RESULT] @@ -48,10 +48,10 @@ To use DB_RESULT, process in 2 steps: end -{{tip|Provide [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] with the LIST structure convenient for what you need to do with the results. }} +{{tip|Provide [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] with the LIST structure convenient for what you need to do with the results. }} -* You want to '''select part''' of the result set: you can set an action in [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] that will be executed each time a row is loaded. This action can for instance manipulate current row and define a stop condition. -** You need to define a descendant of class ACTION and set it to [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] : +* You want to '''select part''' of the result set: you can set an action in [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] that will be executed each time a row is loaded. This action can for instance manipulate current row and define a stop condition. +** You need to define a descendant of class ACTION and set it to [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] : class MY_ACTION @@ -75,7 +75,7 @@ inherit Result := i >= Max_result end -** Then set action to [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] : +** Then set action to [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] : selection: DB_SELECTION action: MY_ACTION diff --git a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki index 4daf06c1..acd6555d 100644 --- a/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki +++ b/documentation/trunk/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki @@ -3,14 +3,14 @@ [[Property:uuid|9979af90-07c3-8b20-448e-04454a75c801]] When sending requests to the database, the request is first parsed then executed. Instead of parsing many times the same requests, i.e. with only changes in expression values, most of RDBMS enable to '''precompile''' requests. These requests can then be executed as routines and are identified by a name and a signature. -EiffelStore lets you use stored procedures with [[ref:/libraries/store/reference/db_proc_flatshort|DB_PROC]] class to: +EiffelStore lets you use stored procedures with [[ref:libraries/store/reference/db_proc_flatshort|DB_PROC]] class to: * [[#execute|Execute]] a stored procedure. * [[#create|Create]] a stored procedure. ==Executing a stored procedure== To execute a stored procedure: -* Create a [[ref:/libraries/store/reference/db_proc_flatshort|DB_PROC]] object and load the stored procedure you want to use: +* Create a [[ref:libraries/store/reference/db_proc_flatshort|DB_PROC]] object and load the stored procedure you want to use: procedure: DB_PROC @@ -23,9 +23,9 @@ To execute a stored procedure: end -* Execute the procedure through a [[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] (if a result is expected) or a [[ref:/libraries/store/reference/db_change_chart|DB_CHANGE ]] object (otherwise). +* Execute the procedure through a [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] (if a result is expected) or a [[ref:libraries/store/reference/db_change_chart|DB_CHANGE ]] object (otherwise). -{{note|Requests with a result ([[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] ) or without ([[ref:/libraries/store/reference/db_change_chart|DB_CHANGE]] ) are both abstract '''expressions'''. DB_PROC executes an abstract expression using an object of [[ref:/libraries/store/reference/db_expression_chart|DB_EXPRESSION]] type, which corresponds to an abstract expression. [[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] and [[ref:/libraries/store/reference/db_change_chart|DB_CHANGE]] inherits from [[ref:/libraries/store/reference/db_expression_chart|DB_EXPRESSION]] . }} +{{note|Requests with a result ([[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] ) or without ([[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] ) are both abstract '''expressions'''. DB_PROC executes an abstract expression using an object of [[ref:libraries/store/reference/db_expression_chart|DB_EXPRESSION]] type, which corresponds to an abstract expression. [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] and [[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] inherits from [[ref:libraries/store/reference/db_expression_chart|DB_EXPRESSION]] . }} You can execute your request mostly like a basic one: ** Create your request. diff --git a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki index d876f8bb..245c0648 100644 --- a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki +++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki @@ -23,8 +23,8 @@ This sample contains the following class: {{seealso|
-[[ref:/libraries/vision2/reference/ev_accelerator_chart|EV_ACCELERATOR]]
-[[ref:/libraries/vision2/reference/ev_key_chart|EV_KEY]]
+[[ref:libraries/vision2/reference/ev_accelerator_chart|EV_ACCELERATOR]]
+[[ref:libraries/vision2/reference/ev_key_chart|EV_KEY]]
}} diff --git a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki index a13161fb..cd9de196 100644 --- a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki +++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki @@ -6,9 +6,9 @@ EiffelVision 2 ships with a number of samples provided to demonstrate different * [[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]] . +* [[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/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki index e13a4c1d..766ba6b2 100644 --- a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki +++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki @@ -29,7 +29,7 @@ This sample contains the following class: {{seealso|
EV_VIEWPORT
EV_SPIN_BUTTON
-[[ref:/libraries/vision2/reference/ev_button_chart|EV_BUTTON]]
+[[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]]
}} diff --git a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki index 636b8aa7..a7d2ef29 100644 --- a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki +++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki @@ -15,7 +15,7 @@ The EiffelVision 2 library includes the following interface clusters: * The [[Properties| properties]] cluster contains classes that allow for the customization of Vision 2 widgets and items. Classes such as [[ref:libraries/vision2/reference/ev_colorizable_chart|EV_COLORIZABLE]] and [[ref:libraries/vision2/reference/ev_fontable_chart|EV_FONTABLE]] contain routines that allow for (respectively) color and font to be altered for a widget. -* The [[Support| support]] cluster includes classes that provide more professional touches to an application, whether these are keyboard shortcuts ([[ref:libraries/vision2/reference/ev_accelerator_list_chart|EV_ACCELERATOR_LIST]]) or graphical output ([[ref:libraries/vision2/reference/ev_graphical_format_chart|EV_GRAPHICAL_FORMAT]]) for drawable widgets such as [[ref:/libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]] . +* The [[Support| support]] cluster includes classes that provide more professional touches to an application, whether these are keyboard shortcuts ([[ref:libraries/vision2/reference/ev_accelerator_list_chart|EV_ACCELERATOR_LIST]]) or graphical output ([[ref:libraries/vision2/reference/ev_graphical_format_chart|EV_GRAPHICAL_FORMAT]]) for drawable widgets such as [[ref:libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]] . * The [[Figures| figures]] cluster allows for the projection of two-dimensional shapes (figures) onto an [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]] or printer via the use of an [[ref:libraries/vision2/reference/ev_projector_chart|EV_PROJECTOR]] . diff --git a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki index adb1d56a..b115ed4f 100644 --- a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki +++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki @@ -8,7 +8,7 @@ The kernel cluster contains classes that provide functionality common to most Wi [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is the basis for every EiffelVision 2 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 compile your system on. It is also where the main event loop that drives your application is executed. -{{note|It is an '''error''' to attempt to create any EiffelVision 2 components before the application object has been created (see the Flat Contracts view of [[ref:/libraries/vision2/reference/ev_environment_chart|EV_ENVIRONMENT]]). }} +{{note|It is an '''error''' to attempt to create any EiffelVision 2 components before the application object has been created (see the Flat Contracts view of [[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 EiffelVision 2 application. A simple method of using EV_APPLICATION is as follows: diff --git a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki index c82a4aea..7ba96ce5 100644 --- a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki +++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki @@ -35,7 +35,7 @@ A simple example of this is demonstrated here: button2.drop_actions.extend (agent print (?)) -Because print takes an argument of type [[ref:/libraries/base/reference/string_8_chart|STRING_8]], button2 becomes a valid drop-target for the pebble contained by 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 complete the transport. The transport can be canceled anytime with a simple left click, just as you would do in EiffelStudio. +Because print takes an argument of type [[ref:libraries/base/reference/string_8_chart|STRING_8]], button2 becomes a valid drop-target for the pebble contained by 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 complete the transport. The transport can be canceled anytime with a simple left click, just as you would do in EiffelStudio. {{note|Any type of object can be used as the '''pebble'''. When a transport completes, the '''pebble''' that was transported is passed as an argument to all agents in the '''target's''' drop_actions list to which the '''pebble''' [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Conformance|conforms]].

}} diff --git a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki index 554df7aa..455941fb 100644 --- a/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki +++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki @@ -3,15 +3,15 @@ [[Property:uuid|595bb73e-146a-ea19-221f-40f3415aad34]] ==What Is a Widget?== -A Widget is the fundamental building block of your application's GUI. Components such as Windows, Buttons, Text fields, Check Boxes, List Boxes and layout Containers are examples of widgets. The widget set in EiffelVision 2 provides you with the flexibility to easily create powerful graphical applications. All widgets in EiffelVision 2 inherit from [[ref:/libraries/vision2/reference/ev_widget_chart| EV_WIDGET]], thus the features provided in EV_WIDGET may be called on any widget. +A Widget is the fundamental building block of your application's GUI. Components such as Windows, Buttons, Text fields, Check Boxes, List Boxes and layout Containers are examples of widgets. The widget set in EiffelVision 2 provides you with the flexibility to easily create powerful graphical applications. All widgets in EiffelVision 2 inherit from [[ref:libraries/vision2/reference/ev_widget_chart| EV_WIDGET]], thus the features provided in EV_WIDGET may be called on any widget. ==Variations of Widgets== Within EiffelVision 2, widgets have been classified into three different groups: -* [[Primitives|Primitives]] — These are elements of the user interface that are mainly responsible for interaction with the user, such as an [[ref:/libraries/vision2/reference/ev_button_chart|EV_BUTTON]]. +* [[Primitives|Primitives]] — These are elements of the user interface that are mainly responsible for interaction with the user, such as an [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]]. -* [[Containers|Containers]] — These are used to contain other widgets and position them in a certain way, such as an [[ref:/libraries/vision2/reference/ev_vertical_box_chart| EV_VERTICAL_BOX ]] that stacks its child widgets one by one vertically. +* [[Containers|Containers]] — These are used to contain other widgets and position them in a certain way, such as an [[ref:libraries/vision2/reference/ev_vertical_box_chart| EV_VERTICAL_BOX ]] that stacks its child widgets one by one vertically. * [[EiffelVision Dialogs|Dialogs]] — These are pop up dialog boxes used for interacting with the user for tasks such as opening a file (EV_FILE_OPEN_DIALOG) or displaying a message (EV_MESSAGE_DIALOG). You may also construct your own dialog boxes by inheriting from EV_DIALOG. diff --git a/documentation/trunk/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki b/documentation/trunk/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki index a257cf57..d9ef0d3e 100644 --- a/documentation/trunk/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki +++ b/documentation/trunk/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki @@ -10,7 +10,7 @@ In the preceding examples each participant in a communication had to get ready t The commands are objects, instances of a general-purpose class COMMAND or its proper descendants. Class COMMAND has, among its features, a procedure execute which executes the current command; some commands are undoable and have an undo procedure. -In EiffelNet the possible events associated with a socket will be of three kind: a read event; a write event; or a special event (out of bounds operation). The command classes will be descendants of [[ref:/libraries/net/reference/poll_command_chart|POLL_COMMAND]], an heir of COMMAND. +In EiffelNet the possible events associated with a socket will be of three kind: a read event; a write event; or a special event (out of bounds operation). The command classes will be descendants of [[ref:libraries/net/reference/poll_command_chart|POLL_COMMAND]], an heir of COMMAND. ===9.2 Command classes=== diff --git a/documentation/trunk/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki b/documentation/trunk/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki index 87f8ccb3..456d7c9d 100644 --- a/documentation/trunk/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki +++ b/documentation/trunk/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki @@ -94,7 +94,7 @@ A Special_C++_feature, if present, indicates one of the following, all illustrat * If the special feature's declaration simply starts with a C++ class name, followed by the associated file name, it indicates that the Eiffel feature will call a C++ member function (also known as a "method") from that class. The name of the member function is by default the same as the name of the Eiffel feature; as usual, you can specify a different name through the alias clause of the external declaration. * If the declaration starts with static, it indicates a call to a C++ static function. * If the declaration starts with new, it indicates a call to one of the constructors in the C++ class, which will create a new instance of that class and apply to it the corresponding constructor function. -* If the declaration starts with delete, it indicates a call to a destructor from the C++ class. In this case the Eiffel class may inherit [[ref:/libraries/base/reference/memory_chart|MEMORY]] and redefine the dispose procedure to execute the destructor operations whenever the Eiffel objects are garbage-collected. +* If the declaration starts with delete, it indicates a call to a destructor from the C++ class. In this case the Eiffel class may inherit [[ref:libraries/base/reference/memory_chart|MEMORY]] and redefine the dispose procedure to execute the destructor operations whenever the Eiffel objects are garbage-collected. * If the declaration starts with data_member, it indicates access to a data member (attribute in Eiffel terminology) from the C++ class. The rest of the possible components are the same as in the C interface: Signature to specify types for arguments and results; possible Include file. diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki index 2cd9a802..8d83837d 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki @@ -1,7 +1,7 @@ [[Property:title|Redefining main_window]] [[Property:weight|1]] [[Property:uuid|f7bfd5d0-86ef-5387-ba79-5461a516bcf6]] -When you inherit [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] , you will need to implement the deferred feature main_window as a once function. This will be the main window of your application, and can be any descendent of [[ref:libraries/wel/reference/wel_composite_window_chart|WEL_COMPOSITE_WINDOW]] . +When you inherit [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] , you will need to implement the deferred feature main_window as a once function. This will be the main window of your application, and can be any descendent of [[ref:libraries/wel/reference/wel_composite_window_chart|WEL_COMPOSITE_WINDOW]] . {{note|. See [[Tutorial Step 2|step2]] in the [[WEL Tutorial|tutorial]] for a simple demonstration of how to do this. }} diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki index 2ef9777f..faedb7f8 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki @@ -1,20 +1,20 @@ [[Property:title|windows cluster]] [[Property:weight|-1]] [[Property:uuid|dc1af280-2e91-713c-751f-e88ce87197cf]] -This cluster contains the different types of windows available to a [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . +This cluster contains the different types of windows available to a [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . The following effective window types are available: -* [[ref:/libraries/wel/reference/wel_popup_window_chart|WEL_POPUP_WINDOW]] -* [[ref:/libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] -* [[ref:/libraries/wel/reference/wel_modeless_dialog_chart|WEL_MODELESS_DIALOG]] -* [[ref:/libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] -* [[ref:/libraries/wel/reference/wel_mdi_client_window_chart|WEL_MDI_CLIENT_WINDOW]] -* [[ref:/libraries/wel/reference/wel_mdi_child_window_chart|WEL_MDI_CHILD_WINDOW]] -* [[ref:/libraries/wel/reference/wel_main_dialog_chart|WEL_MAIN_DIALOG]] -* [[ref:/libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] -* [[ref:/libraries/wel/reference/wel_control_window_chart|WEL_CONTROL_WINDOW]] +* [[ref:libraries/wel/reference/wel_popup_window_chart|WEL_POPUP_WINDOW]] +* [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] +* [[ref:libraries/wel/reference/wel_modeless_dialog_chart|WEL_MODELESS_DIALOG]] +* [[ref:libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] +* [[ref:libraries/wel/reference/wel_mdi_client_window_chart|WEL_MDI_CLIENT_WINDOW]] +* [[ref:libraries/wel/reference/wel_mdi_child_window_chart|WEL_MDI_CHILD_WINDOW]] +* [[ref:libraries/wel/reference/wel_main_dialog_chart|WEL_MAIN_DIALOG]] +* [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] +* [[ref:libraries/wel/reference/wel_control_window_chart|WEL_CONTROL_WINDOW]] -{{note|A WEL application must contain at least one window. See the [[WEL Tutorial]] for details of how to set up your first window within a [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . }} +{{note|A WEL application must contain at least one window. See the [[WEL Tutorial]] for details of how to set up your first window within a [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . }} diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki index 7f6f450d..99ab2ae5 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki @@ -28,9 +28,9 @@ This sample contains the following classes: {{seealso|
[[WEL_LIST_VIEW|WEL_LIST_VIEW]]
-[[ref:/libraries/wel/reference/wel_combo_box_chart|WEL_COMBO_BOX]]
+[[ref:libraries/wel/reference/wel_combo_box_chart|WEL_COMBO_BOX]]
[[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]]
-[[ref:/libraries/wel/reference/wel_edit_chart|WEL_EDIT]]
+[[ref:libraries/wel/reference/wel_edit_chart|WEL_EDIT]]
[[WEL_RADIO_BUTTON|WEL_RADIO_BUTTON]]
[[WEL_PUSH_BUTTON|WEL_CHECK_BUTTON]]
[[WEL_MULTIPLE_LINE_EDIT|WEL_MULTIPLE_LINE_EDIT]]
diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki index dee53bf2..e20b34ec 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki @@ -24,7 +24,7 @@ This sample contains only one class: {{seealso|
[[Tutorial Step 1|tutorial step 1]]
-[[ref:/libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] }} +[[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] }} diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki index 4b7267b2..44c43569 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki @@ -29,7 +29,7 @@ This sample contains the following classes: * RICHEDIT_DEMO {{seealso|
-[[ref:/libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]]
+[[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]]
[[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]]
[[WEL_SAVE_FILE_DIALOG|WEL_SAVE_FILE_DIALOG]]
[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]]
diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki index b646cf3c..12166c53 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki @@ -27,7 +27,7 @@ This sample contains the following classes: {{seealso|
-[[ref:/libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]] }} +[[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]] }} diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki index 3ffa2eb4..4120bee0 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki @@ -28,7 +28,7 @@ This sample contains the following classes: * APPLICATION_IDS {{seealso|
-[[ref:/libraries/wel/reference/wel_tree_view_chart|WEL_TREE_VIEW]] }} +[[ref:libraries/wel/reference/wel_tree_view_chart|WEL_TREE_VIEW]] }} diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki index b1a4deea..c85b8c5d 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki @@ -15,7 +15,7 @@ To compile the example: * Click '''OK'''. ==Running== -After launching the sample, you should see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. If you click the left mouse button in the client area of the window, the coordinates of the click (Relative to the top left of the client area), will be displayed. Clicking the [[ref:/libraries/wel/reference/wel_push_button_chart|WEL_PUSH_BUTTON]] marked "Clear" will clear the client area of the window. +After launching the sample, you should see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. If you click the left mouse button in the client area of the window, the coordinates of the click (Relative to the top left of the client area), will be displayed. Clicking the [[ref:libraries/wel/reference/wel_push_button_chart|WEL_PUSH_BUTTON]] marked "Clear" will clear the client area of the window. ==Under the Hood== A [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] is used to display output in the client area of the window during the execution of on_left_button_down which has been redefined in MAIN_WINDOW. diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki index ef6b87a3..bf15de38 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki @@ -1,7 +1,7 @@ [[Property:title|Tutorial Step 1]] [[Property:weight|0]] [[Property:uuid|b952d232-1ef9-04a8-bac4-117185aa316d]] -This sample shows you how to set up your first [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] consisting of a single [[ref:/libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . This is one of the simplest WEL applications you can write, and the output is shown below: +This sample shows you how to set up your first [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] consisting of a single [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . This is one of the simplest WEL applications you can write, and the output is shown below: [[Image:step1|step1]]
@@ -24,9 +24,9 @@ After you launch the sample, You should see the window displayed in the screen a ==Under the Hood== -Although this system does nothing except create and display a [[ref:/libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] , it shows how to set up your first [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . +Although this system does nothing except create and display a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] , it shows how to set up your first [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . -This sample only contains one class, TUTORIAL_STEP1 which inherits [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] and redefines main_window +This sample only contains one class, TUTORIAL_STEP1 which inherits [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] and redefines main_window {{seealso|
[[Inheriting WEL_APPLICATION|Inheriting WEL application]]
diff --git a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki index cb57f795..f52d2690 100644 --- a/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki +++ b/documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki @@ -21,7 +21,7 @@ This sample builds on tutorial [[Tutorial Step 7|step 7]] , and also demonstrate After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. Selecting "Line_thickness" from the "Line" menu, will display a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] which allows you to change the thickness of the line that is drawn. If you select "Exit" from the "File" menu, you will be prompted if you wish to exit the application. Selecting "New" from the "File" menu will clear the window. Selecting "Save" from the "File" menu will display a [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] which allows you to specify the filename and location of the picture you have drawn. Selecting "Open" from the "File" menu will display a [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] which allows you to specify a previously saved drawing to open. ==Under the Hood== -The [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] and the [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] are both activated from the redefinition of on_menu_command. A new class, LINES is now used to store the lines drawn by the user and this inherits [[ref:/libraries/base/reference/storable_chart|STORABLE]] which allows it to be easily stored and retrieved. +The [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] and the [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] are both activated from the redefinition of on_menu_command. A new class, LINES is now used to store the lines drawn by the user and this inherits [[ref:libraries/base/reference/storable_chart|STORABLE]] which allows it to be easily stored and retrieved. This sample contains the following classes: * TUTORIAL_STEP6 * MAIN_WINDOW @@ -32,8 +32,8 @@ This sample contains the following classes: * LINE {{seealso|
-[[ref:/libraries/wel/reference/wel_save_file_dialog_chart|Save file dialog]]
-[[ref:/libraries/wel/reference/wel_open_file_dialog_chart|Open file dialog]] }} +[[ref:libraries/wel/reference/wel_save_file_dialog_chart|Save file dialog]]
+[[ref:libraries/wel/reference/wel_open_file_dialog_chart|Open file dialog]] }} diff --git a/documentation/trunk/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki b/documentation/trunk/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki index 0ccae9fe..deabeab9 100644 --- a/documentation/trunk/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki +++ b/documentation/trunk/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki @@ -9,7 +9,7 @@ The process of recognizing the successive tokens of a text is called lexical ana Besides recognizing the tokens, it is usually necessary to recognize the deeper syntactic structure of the text. This process is called '''parsing''' or '''syntax analysis''' and is studied in the next chapter. -Figure 1 shows the inheritance structure of the classes discussed in this chapter. Class [[ref:/libraries/parse/reference/l_interface_chart|L_INTERFACE]] has also been included although we will only study it in the [[EiffelParse Tutorial]]; it belongs to the Parse library, where it takes care of the interface between parsing and lexical analysis. +Figure 1 shows the inheritance structure of the classes discussed in this chapter. Class [[ref:libraries/parse/reference/l_interface_chart|L_INTERFACE]] has also been included although we will only study it in the [[EiffelParse Tutorial]]; it belongs to the Parse library, where it takes care of the interface between parsing and lexical analysis. [[Image:figure1]] @@ -34,37 +34,37 @@ The classes of the EiffelLex library make it possible to define lexical grammars ===Overview of the classes=== -For the user of the EiffelLex library, the classes of most direct interest are [[ref:/libraries/lex/reference/token_chart|TOKEN]] , [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , [[ref:/libraries/lex/reference/metalex_chart|METALEX]] and [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] . +For the user of the EiffelLex library, the classes of most direct interest are [[ref:libraries/lex/reference/token_chart|TOKEN]] , [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , [[ref:libraries/lex/reference/metalex_chart|METALEX]] and [[ref:libraries/lex/reference/scanning_chart|SCANNING]] . -An instance of [[ref:/libraries/lex/reference/token_chart|TOKEN]] describes a token read from an input file being analyzed, with such properties as the token type, the corresponding string and the position in the text (line, column) where it was found. +An instance of [[ref:libraries/lex/reference/token_chart|TOKEN]] describes a token read from an input file being analyzed, with such properties as the token type, the corresponding string and the position in the text (line, column) where it was found. -An instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] is a lexical analyzer for a certain lexical grammar. Given a reference to such an instance, say analyzer, you may analyze an input text through calls to the features of class [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , for example: +An instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] is a lexical analyzer for a certain lexical grammar. Given a reference to such an instance, say analyzer, you may analyze an input text through calls to the features of class [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , for example: analyzer.get_token -Class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] defines facilities for building such lexical analyzers. In particular, it provides features for reading the grammar from a file and building the corresponding analyzer. Classes that need to build and use lexical analyzers may be written as descendants of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] to benefit from its general-purpose facilities. +Class [[ref:libraries/lex/reference/metalex_chart|METALEX]] defines facilities for building such lexical analyzers. In particular, it provides features for reading the grammar from a file and building the corresponding analyzer. Classes that need to build and use lexical analyzers may be written as descendants of [[ref:libraries/lex/reference/metalex_chart|METALEX]] to benefit from its general-purpose facilities. -Class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] is one such descendant of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . It contains all the facilities needed to build an ordinary lexical analyzer and apply it to the analysis of input texts. Because these facilities are simpler to use and are in most cases sufficient, SCANNING will be discussed first; the finer-grain facilities of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] are described towards the end of this chapter. +Class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] is one such descendant of [[ref:libraries/lex/reference/metalex_chart|METALEX]] . It contains all the facilities needed to build an ordinary lexical analyzer and apply it to the analysis of input texts. Because these facilities are simpler to use and are in most cases sufficient, SCANNING will be discussed first; the finer-grain facilities of [[ref:libraries/lex/reference/metalex_chart|METALEX]] are described towards the end of this chapter. -These classes internally rely on others, some of which may be useful for more advanced applications. [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , one of the supporting classes, will be introduced after [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . +These classes internally rely on others, some of which may be useful for more advanced applications. [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , one of the supporting classes, will be introduced after [[ref:libraries/lex/reference/metalex_chart|METALEX]] . ===Library example=== The EiffelStudio delivery includes (in the examples/library/lex subdirectory) a simple example using the EiffelLex library classes. The example applies EiffelLex library facilities to the analysis of a language which is none other than Eiffel itself. -The root class of that example, EIFFEL_SCAN, is only a few lines long; it relies on the general mechanism provided by [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] (see below). The actual lexical grammar is given by a lexical grammar file (a concept explained below): the file of name eiffel_regular in the same directory. +The root class of that example, EIFFEL_SCAN, is only a few lines long; it relies on the general mechanism provided by [[ref:libraries/lex/reference/scanning_chart|SCANNING]] (see below). The actual lexical grammar is given by a lexical grammar file (a concept explained below): the file of name eiffel_regular in the same directory. ===Dealing with finite automata=== -Lexical analysis relies on the theory of finite automata. The most advanced of the classes discussed in this chapter, [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , relies on classes describing various forms of automata: -* [[ref:/libraries/lex/reference/dfa_chart|DFA]] : deterministic finite automata. -* [[ref:/libraries/lex/reference/pdfa_chart|PDFA]] : partially deterministic finite automata. -* [[ref:/libraries/lex/reference/ndfa_chart|NDFA]] : non-deterministic finite automata. -* [[ref:/libraries/lex/reference/automaton_chart|AUTOMATON]] , the most general: finite automata. -* [[ref:/libraries/lex/reference/fixed_automaton_chart|FIXED_AUTOMATON]] , [[ref:/libraries/lex/reference/linked_automaton_chart|LINKED_AUTOMATON]] . +Lexical analysis relies on the theory of finite automata. The most advanced of the classes discussed in this chapter, [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , relies on classes describing various forms of automata: +* [[ref:libraries/lex/reference/dfa_chart|DFA]] : deterministic finite automata. +* [[ref:libraries/lex/reference/pdfa_chart|PDFA]] : partially deterministic finite automata. +* [[ref:libraries/lex/reference/ndfa_chart|NDFA]] : non-deterministic finite automata. +* [[ref:libraries/lex/reference/automaton_chart|AUTOMATON]] , the most general: finite automata. +* [[ref:libraries/lex/reference/fixed_automaton_chart|FIXED_AUTOMATON]] , [[ref:libraries/lex/reference/linked_automaton_chart|LINKED_AUTOMATON]] . -These classes may also be useful for systems that need to manipulate finite automata for applications other than lexical analysis. The interface of [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , which includes the features from [[ref:/libraries/lex/reference/automaton_chart|AUTOMATON]] , [[ref:/libraries/lex/reference/ndfa_chart|NDFA]] and [[ref:/libraries/lex/reference/pdfa_chart|PDFA]] , will provide the essential information. +These classes may also be useful for systems that need to manipulate finite automata for applications other than lexical analysis. The interface of [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , which includes the features from [[ref:libraries/lex/reference/automaton_chart|AUTOMATON]] , [[ref:libraries/lex/reference/ndfa_chart|NDFA]] and [[ref:libraries/lex/reference/pdfa_chart|PDFA]] , will provide the essential information. ==TOKENS== @@ -78,24 +78,24 @@ A lexical analyzer built through any of the techniques described in the rest of ==BUILDING AND USING LEXICAL ANALYZERS== The general method for performing lexical analysis is the following. -# Create an instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , giving a lexical analyzer for the desired grammar. +# Create an instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , giving a lexical analyzer for the desired grammar. # Store the analyzer into a file. # Retrieve the analyzer from the file. -# Use the analyzer to analyze the tokens of one or more input texts by calling the various features of class [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] on this object. +# Use the analyzer to analyze the tokens of one or more input texts by calling the various features of class [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] on this object. -Steps 2 and 3 are obviously unnecessary if this process is applied as a single sequence. But in almost all practical cases you will want to use the same grammar to analyze many different input texts. Then steps 1 and 2 will be performed once and for all as soon as the lexical grammar is known, yielding an instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] that step 2 stores into a file; then in every case that requires analyzing a text you will simply retrieve the analyzer and apply it, performing steps 3 and 4 only. +Steps 2 and 3 are obviously unnecessary if this process is applied as a single sequence. But in almost all practical cases you will want to use the same grammar to analyze many different input texts. Then steps 1 and 2 will be performed once and for all as soon as the lexical grammar is known, yielding an instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] that step 2 stores into a file; then in every case that requires analyzing a text you will simply retrieve the analyzer and apply it, performing steps 3 and 4 only. -The simplest way to store and retrieve the instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] and all related objects is to use the facilities of class [[ref:/libraries/base/reference/storable_chart|STORABLE]] : procedure store and one of the retrieval procedures. To facilitate this process, [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] inherits from [[ref:/libraries/base/reference/storable_chart|STORABLE]] . +The simplest way to store and retrieve the instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] and all related objects is to use the facilities of class [[ref:libraries/base/reference/storable_chart|STORABLE]] : procedure store and one of the retrieval procedures. To facilitate this process, [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] inherits from [[ref:libraries/base/reference/storable_chart|STORABLE]] . -The next sections explain how to perform these various steps. In the most common case, the best technique is to inherit from class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , which provides a framework for retrieving an analyzer file if it exists, creating it from a grammar description otherwise, and proceed with the lexical analysis of one or more input texts. +The next sections explain how to perform these various steps. In the most common case, the best technique is to inherit from class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , which provides a framework for retrieving an analyzer file if it exists, creating it from a grammar description otherwise, and proceed with the lexical analysis of one or more input texts. ==LEXICAL GRAMMAR FILES AND CLASS SCANNING== -Class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] may be used as an ancestor by classes that need to perform lexical analysis. When using [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] you will need a '''lexical grammar file''' that contains the description of the lexical grammar. Since it is easy to edit and adapt a file without modifying the software proper, this technique provides flexibility and supports the incremental development and testing of lexical analyzers. +Class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] may be used as an ancestor by classes that need to perform lexical analysis. When using [[ref:libraries/lex/reference/scanning_chart|SCANNING]] you will need a '''lexical grammar file''' that contains the description of the lexical grammar. Since it is easy to edit and adapt a file without modifying the software proper, this technique provides flexibility and supports the incremental development and testing of lexical analyzers. ===The build procedure=== -To obtain a lexical analyzer in a descendant of class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , use the procedure +To obtain a lexical analyzer in a descendant of class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , use the procedure build (store_file_name, grammar_file_name: STRING) @@ -146,7 +146,7 @@ This will read in and process successive input tokens. Procedure analyze The initial action begin_analysis, which by default prints a header, and the terminal action end_analysis, which by default does nothing, may also be redefined. -To build lexical analyzers which provide a higher degree of flexibility, use [[ref:/libraries/lex/reference/metalex_chart|METALEX]] or [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , as described in the last part of this chapter. +To build lexical analyzers which provide a higher degree of flexibility, use [[ref:libraries/lex/reference/metalex_chart|METALEX]] or [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , as described in the last part of this chapter. ==ANALYZING INPUT== @@ -154,9 +154,9 @@ Let us look more precisely at how we can use a lexical analyzer to analyze an in ===Class LEXICAL=== -Procedure analyze takes care of the most common needs of lexical analysis. But if you need more advanced lexical analysis facilities you will need an instance of class [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] (a direct instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] itself or of one of its proper descendants). If you are using class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] as described above, you will have access to such an instance through the attribute analyzer. +Procedure analyze takes care of the most common needs of lexical analysis. But if you need more advanced lexical analysis facilities you will need an instance of class [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] (a direct instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] itself or of one of its proper descendants). If you are using class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] as described above, you will have access to such an instance through the attribute analyzer. -This discussion will indeed assume that you have an entity attached to an instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] . The name of that entity is assumed to be analyzer, although it does not need to be the attribute from [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] . You can apply to that analyzer the various exported features features of class [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , explained below. All the calls described below should use analyzer as their target, as in +This discussion will indeed assume that you have an entity attached to an instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] . The name of that entity is assumed to be analyzer, although it does not need to be the attribute from [[ref:libraries/lex/reference/scanning_chart|SCANNING]] . You can apply to that analyzer the various exported features features of class [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , explained below. All the calls described below should use analyzer as their target, as in analyzer.set_file ("my_file_name") @@ -168,12 +168,12 @@ To create a new analyzer, use create analyzer.make_new -You may also retrieve an analyzer from a previous session. [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] is a descendant from [[ref:/libraries/base/reference/storable_chart|STORABLE]] , so you can use feature retrieved for that purpose. In a descendant of [[ref:/libraries/base/reference/storable_chart|STORABLE]] , simply write +You may also retrieve an analyzer from a previous session. [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] is a descendant from [[ref:libraries/base/reference/storable_chart|STORABLE]] , so you can use feature retrieved for that purpose. In a descendant of [[ref:libraries/base/reference/storable_chart|STORABLE]] , simply write analyzer ?= retrieved -If you do not want to make the class a descendant of [[ref:/libraries/base/reference/storable_chart|STORABLE]] , use the creation procedure make of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , not to be confused with make_new above: +If you do not want to make the class a descendant of [[ref:libraries/base/reference/storable_chart|STORABLE]] , use the creation procedure make of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , not to be confused with make_new above: create analyzer.make analyzer ?= analyzer.retrieved @@ -183,12 +183,12 @@ If you do not want to make the class a descendant of [[ref:/libraries/base/refer To analyze a text, call set_file or set_string to specify the document to be parsed. With the first call, the analysis will be applied to a file; with the second, to a string. -{{note|if you use procedure analyze of [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , you do not need any such call, since analyze calls set_file on the file name passed as argument. }} +{{note|if you use procedure analyze of [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , you do not need any such call, since analyze calls set_file on the file name passed as argument. }} ===Obtaining the tokens=== The basic procedure for analyzing successive tokens in the text is get_token, which reads in one token and sets up various attributes of the analyzer to record properties of that token: -* last_token, a function of type [[ref:/libraries/lex/reference/token_chart|TOKEN]] , which provides all necessary information on the last token read. +* last_token, a function of type [[ref:libraries/lex/reference/token_chart|TOKEN]] , which provides all necessary information on the last token read. * token_line_number and token_column_number, to know where the token is in the text. These queries return results of type INTEGER. * token_type, giving the regular expression type, identified by its integer number (which is the value No_token if no correct token was recognized). * other_possible_tokens, an array giving all the other possible token types of the last token. (If token_type is No_token the array is empty.) @@ -218,13 +218,13 @@ Here is the most common way of using the preceding facilities: end_analysis -This scheme is used by procedure analyze of class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , so that in standard cases you may simply inherit from that class and redefine procedures begin_analysis, do_a_token, and end_analysis. If you are not inheriting from [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , these names simply denote procedures that you must provide. +This scheme is used by procedure analyze of class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , so that in standard cases you may simply inherit from that class and redefine procedures begin_analysis, do_a_token, and end_analysis. If you are not inheriting from [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , these names simply denote procedures that you must provide. ==REGULAR EXPRESSIONS== The EiffelLex library supports a powerful set of construction mechanisms for describing the various types of tokens present in common languages such as programming languages, specification languages or just text formats. These mechanisms are called '''regular expressions'''; any regular expression describes a set of possible tokens, called the '''specimens''' of the regular expression. -Let us now study the format of regular expressions. This format is used in particular for the lexical grammar files needed by class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] and (as seen below) by procedure read_grammar of class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . The ''eiffel_regular'' grammar file in the examples directory provides an extensive example. +Let us now study the format of regular expressions. This format is used in particular for the lexical grammar files needed by class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] and (as seen below) by procedure read_grammar of class [[ref:libraries/lex/reference/metalex_chart|METALEX]] . The ''eiffel_regular'' grammar file in the examples directory provides an extensive example. Each regular expression denotes a set of tokens. For example, the first regular expression seen above,
@@ -401,7 +401,7 @@ BOOLEAN {{caution|Every keyword in the keyword section must be a specimen of one of the token types defined for the grammar, and that token type must be the last one defined in the lexical grammar file, just before the '''Keywords''' line. So in Eiffel where the keywords have the same lexical structure as identifiers, the last line before the keywords must be the definition of the token type ''Identifier'', as shown above. }} -{{note|The rule that all keywords must be specimens of one token type is a matter of convenience and simplicity, and only applies if you are using SCANNING and lexical grammar files. There is no such restriction if you rely directly on the more general facilities provided by [[ref:/libraries/lex/reference/metalex_chart|METALEX]] or [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] . Then different keywords may be specimens of different regular expressions; you will have to specify the token type of every keyword, as explained later in this chapter. }} +{{note|The rule that all keywords must be specimens of one token type is a matter of convenience and simplicity, and only applies if you are using SCANNING and lexical grammar files. There is no such restriction if you rely directly on the more general facilities provided by [[ref:libraries/lex/reference/metalex_chart|METALEX]] or [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] . Then different keywords may be specimens of different regular expressions; you will have to specify the token type of every keyword, as explained later in this chapter. }} ===Case sensitivity=== @@ -433,19 +433,19 @@ The inverse call, corresponding to the default rule, is keywords_ignore_case -Either of these calls must be executed before you define any keywords; if you are using [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , this means before calling procedure build. Once set, the keyword case-sensitivity policy cannot be changed. +Either of these calls must be executed before you define any keywords; if you are using [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , this means before calling procedure build. Once set, the keyword case-sensitivity policy cannot be changed. ==USING METALEX TO BUILD A LEXICAL ANALYZER== (You may skip the rest of this chapter if you only need simple lexical facilities.) -Class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , as studied above, relies on a class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . In some cases, you may prefer to use the features of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] directly. Since [[ref:libraries/lex/reference/scanning_chart|SCANNING]] inherits from [[ref:/libraries/lex/reference/metalex_chart|METALEX]] , anything you do with [[ref:/libraries/lex/reference/metalex_chart|METALEX]] can in fact be done with [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , but you may wish to stay with just [[ref:/libraries/lex/reference/metalex_chart|METALEX]] if you do not need the additional features of [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] . +Class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , as studied above, relies on a class [[ref:libraries/lex/reference/metalex_chart|METALEX]] . In some cases, you may prefer to use the features of [[ref:libraries/lex/reference/metalex_chart|METALEX]] directly. Since [[ref:libraries/lex/reference/scanning_chart|SCANNING]] inherits from [[ref:libraries/lex/reference/metalex_chart|METALEX]] , anything you do with [[ref:libraries/lex/reference/metalex_chart|METALEX]] can in fact be done with [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , but you may wish to stay with just [[ref:libraries/lex/reference/metalex_chart|METALEX]] if you do not need the additional features of [[ref:libraries/lex/reference/scanning_chart|SCANNING]] . ===Steps in using METALEX=== -[[ref:/libraries/lex/reference/metalex_chart|METALEX]] has an attribute analyzer which will be attached to a lexical analyzer. This class provides tools for building a lexical analyzer incrementally through explicit feature calls; you can still use a lexical grammar file, but do not have to. +[[ref:libraries/lex/reference/metalex_chart|METALEX]] has an attribute analyzer which will be attached to a lexical analyzer. This class provides tools for building a lexical analyzer incrementally through explicit feature calls; you can still use a lexical grammar file, but do not have to. -The following extract from a typical descendant of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] illustrates the process of building a lexical analyzer in this way: +The following extract from a typical descendant of [[ref:libraries/lex/reference/metalex_chart|METALEX]] illustrates the process of building a lexical analyzer in this way: Upper_identifier, Lower_identifier, Decimal_constant, Octal_constant, Word: INTEGER is unique @@ -467,13 +467,13 @@ The following extract from a typical descendant of [[ref:/libraries/lex/referenc make_analyzer -This example follows the general scheme of building a lexical analyzer with the features of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] , in a class that will normally be a descendant of [[ref:libraries/lex/reference/metalex_chart|METALEX]] : +This example follows the general scheme of building a lexical analyzer with the features of [[ref:libraries/lex/reference/metalex_chart|METALEX]] , in a class that will normally be a descendant of [[ref:libraries/lex/reference/metalex_chart|METALEX]] : # Set options, such as case sensitivity. # Record regular expressions. # Record keywords (this may be interleaved with step 2.) # "Freeze" the analyzer by a call to make_analyzer. -To perform steps 2 to 4 in a single shot and generate a lexical analyzer from a lexical grammar file, as with [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , you may use the procedure +To perform steps 2 to 4 in a single shot and generate a lexical analyzer from a lexical grammar file, as with [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , you may use the procedure read_grammar (grammar_file_name: STRING) @@ -492,7 +492,7 @@ Procedure dollar_w corresponds to the '''$W''' syntax for regul put_nameless_expression ( "$W" ,Word ) -Procedure declare_keyword records a keyword. The first argument is a string containing the keyword; the second argument is the regular expression of which the keyword must be a specimen. The example shows that here - in contrast with the rule enforced by [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] - not all keywords need be specimens of the same regular expression. +Procedure declare_keyword records a keyword. The first argument is a string containing the keyword; the second argument is the regular expression of which the keyword must be a specimen. The example shows that here - in contrast with the rule enforced by [[ref:libraries/lex/reference/scanning_chart|SCANNING]] - not all keywords need be specimens of the same regular expression. The calls seen so far record a number of regular expressions and keywords, but do not give us a lexical analyzer yet. To obtain a usable lexical analyzer, you must call @@ -503,17 +503,17 @@ After that call, you may not record any new regular expression or keyword. The a {{note|for readers knowledgeable in the theory of lexical analysis: one of the most important effects of the call to make_analyzer is to transform the non-deterministic finite automaton resulting from calls such as the ones above into a deterministic finite automaton. }} Remember that if you use procedure read_grammar, you need not worry about make_analyzer, as the former procedure calls the latter. -Another important feature of class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] is procedure store_analyzer, which stores the analyzer into a file whose name is passed as argument, for use by later lexical analysis sessions. To retrieve the analyzer, simply use procedure retrieve_analyzer, again with a file name as argument. +Another important feature of class [[ref:libraries/lex/reference/metalex_chart|METALEX]] is procedure store_analyzer, which stores the analyzer into a file whose name is passed as argument, for use by later lexical analysis sessions. To retrieve the analyzer, simply use procedure retrieve_analyzer, again with a file name as argument. ==BUILDING A LEXICAL ANALYZER WITH LEX_BUILDER== -To have access to the most general set of lexical analysis mechanisms, you may use class [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , which gives you an even finer grain of control than [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . This is not necessary in simple applications. +To have access to the most general set of lexical analysis mechanisms, you may use class [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , which gives you an even finer grain of control than [[ref:libraries/lex/reference/metalex_chart|METALEX]] . This is not necessary in simple applications. ===Building a lexical analyzer=== -[[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] enables you to build a lexical analyzer by describing successive token types and keywords. This is normally done in a descendant of [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] . For each token type, you call a procedure that builds an object, or '''tool''', representing the associated regular expression. +[[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] enables you to build a lexical analyzer by describing successive token types and keywords. This is normally done in a descendant of [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] . For each token type, you call a procedure that builds an object, or '''tool''', representing the associated regular expression. For the complete list of available procedures, refer to the flat-short form of the class; there is one procedure for every category of regular expression studied earlier in this chapter. Two typical examples of calls are: @@ -527,7 +527,7 @@ For the complete list of available procedures, refer to the flat-short form of t Every such procedure call also assigns an integer index to the tool it creates; this number is available through the attribute last_created_tool. You will need to record it into an integer entity, for example Identifier or Letter. ===An example=== -The following extract from a typical descendant of [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] illustrates how to create a tool representing the identifiers of an Eiffel-like language. +The following extract from a typical descendant of [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] illustrates how to create a tool representing the identifiers of an Eiffel-like language. Identifier, Letter, Digit, Underlined, Suffix, Suffix_list: INTEGER diff --git a/documentation/trunk/solutions/text-processing/eiffelparse/eiffelparse-tutorial.wiki b/documentation/trunk/solutions/text-processing/eiffelparse/eiffelparse-tutorial.wiki index 0ce76543..794504d8 100644 --- a/documentation/trunk/solutions/text-processing/eiffelparse/eiffelparse-tutorial.wiki +++ b/documentation/trunk/solutions/text-processing/eiffelparse/eiffelparse-tutorial.wiki @@ -66,14 +66,14 @@ As noted at the beginning of this chapter, it is possible to build a single synt ==LIBRARY CLASSES== The EiffelParse library contains a small number of classes which cover common document processing applications. The classes, whose inheritance structure was shown at the beginning of this chapter, are: -* [[ref:/libraries/parse/reference/construct_chart|CONSTRUCT]] , describing the general notion of syntactical construct. -* [[ref:/libraries/parse/reference/aggregate_chart|AGGREGATE]] , describing constructs of the "aggregate" form. -* [[ref:/libraries/parse/reference/choice_chart|CHOICE]] , describing constructs of the "choice" form. -* [[ref:/libraries/parse/reference/repetition_chart|REPETITION]] , describing constructs of the "repetition" form. -* [[ref:/libraries/parse/reference/terminal_chart|TERMINAL]] , describing "terminal" constructs with no further structure. -* [[ref:/libraries/parse/reference/keyword_chart|KEYWORD]] , describing how to handle keywords. -* [[ref:/libraries/parse/reference/l_interface_chart|L_INTERFACE]] , providing a simple interface with the lexical analysis process and the Lex library. -* [[ref:/libraries/parse/reference/input_chart|INPUT]] , describing how to handle the input document. +* [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] , describing the general notion of syntactical construct. +* [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , describing constructs of the "aggregate" form. +* [[ref:libraries/parse/reference/choice_chart|CHOICE]] , describing constructs of the "choice" form. +* [[ref:libraries/parse/reference/repetition_chart|REPETITION]] , describing constructs of the "repetition" form. +* [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] , describing "terminal" constructs with no further structure. +* [[ref:libraries/parse/reference/keyword_chart|KEYWORD]] , describing how to handle keywords. +* [[ref:libraries/parse/reference/l_interface_chart|L_INTERFACE]] , providing a simple interface with the lexical analysis process and the Lex library. +* [[ref:libraries/parse/reference/input_chart|INPUT]] , describing how to handle the input document. ==EXAMPLES== The EiffelStudio delivery includes (in the examples/library/parse subdirectory) a simple example using the EiffelParse Library classes. The example is a processor for "documents" which describe computations involving polynomials with variables. The corresponding processor is a system which obtains polynomial specifications and variable values from a user, and computes the corresponding polynomials. @@ -100,7 +100,7 @@ Although some notations for syntax descriptions such as BNF allow more than one * A terminal construct has no defining production. This means that it must be defined outside of the syntactical grammar. Terminals indeed come from the '''lexical grammar'''. Every terminal construct corresponds to a token type (regular expression or keyword) of the lexical grammar, for which the parsing duty will be delegated to lexical mechanisms, assumed in the rest of this chapter to be provided by the Lex library although others may be substituted if appropriate. -All specimens of terminal constructs are instances of class [[ref:/libraries/parse/reference/terminal_chart|TERMINAL]] . A special case is that of keyword constructs, which have a single specimen corresponding to a keyword of the language. For example, if is a keyword of Eiffel. Keywords are described by class [[ref:/libraries/parse/reference/keyword_chart|KEYWORD]] , an heir of [[ref:/libraries/parse/reference/terminal_chart|TERMINAL]] . +All specimens of terminal constructs are instances of class [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] . A special case is that of keyword constructs, which have a single specimen corresponding to a keyword of the language. For example, if is a keyword of Eiffel. Keywords are described by class [[ref:libraries/parse/reference/keyword_chart|KEYWORD]] , an heir of [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] . The rest of this section concentrates on the parsing-specific part: non-terminal constructs and productions. Terminals will be studied in the discussion of how to interface parsing with lexical analysis. @@ -158,9 +158,9 @@ The EiffelParse library supports a parsing mechanism based on the concepts of ob ===Class CONSTRUCT=== -The deferred class [[ref:/libraries/parse/reference/construct_chart|CONSTRUCT]] describes the general notion of construct; instances of this class and its descendants are specimens of the constructs of a grammar. +The deferred class [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] describes the general notion of construct; instances of this class and its descendants are specimens of the constructs of a grammar. -Deferred though it may be, [[ref:/libraries/parse/reference/construct_chart|CONSTRUCT]] defines some useful general patterns; for example, its procedure process appears as:
+Deferred though it may be, [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] defines some useful general patterns; for example, its procedure process appears as:
parse if parsed then @@ -170,11 +170,11 @@ Deferred though it may be, [[ref:/libraries/parse/reference/construct_chart|CONS
where procedures parse and semantics are expressed in terms of some more specific procedures, which are deferred. This defines a general scheme while leaving the details to descendants of the class. -Such descendants, given in the library, are classes [[ref:/libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:/libraries/parse/reference/choice_chart|CHOICE]] , [[ref:/libraries/parse/reference/repetition_chart|REPETITION]] and [[ref:/libraries/parse/reference/terminal_chart|TERMINAL]] . They describe the corresponding types of construct, with features providing the operations for parsing their specimens and applying the associated semantic actions. +Such descendants, given in the library, are classes [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:libraries/parse/reference/choice_chart|CHOICE]] , [[ref:libraries/parse/reference/repetition_chart|REPETITION]] and [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] . They describe the corresponding types of construct, with features providing the operations for parsing their specimens and applying the associated semantic actions. ===Building a processor=== -To build a processor for a given grammar, you write a class, called a '''construct class''', for every construct of the grammar, terminal or non-terminal. The class should inherit from [[ref:/libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:/libraries/parse/reference/choice_chart|CHOICE]] , [[ref:/libraries/parse/reference/repetition_chart|REPETITION]] or [[ref:/libraries/parse/reference/terminal_chart|TERMINAL]] depending on the nature of the construct. It describes the production for the construct and any associated semantic actions. +To build a processor for a given grammar, you write a class, called a '''construct class''', for every construct of the grammar, terminal or non-terminal. The class should inherit from [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:libraries/parse/reference/choice_chart|CHOICE]] , [[ref:libraries/parse/reference/repetition_chart|REPETITION]] or [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] depending on the nature of the construct. It describes the production for the construct and any associated semantic actions. To complete the processor, you must choose a "top construct" for that particular processor, and write a root class. In accordance with the object-oriented method, which implies that "roots" and "tops" should be chosen last, these steps are explained at the end of this chapter. @@ -186,9 +186,9 @@ The effect of processing a document with a processor built from a combination of The syntax tree is said to be abstract because it only includes important structural information and does not retain the concrete information such as keywords and separators. Such concrete information, sometimes called "syntactic sugar", serves only external purposes but is of no use for semantic processing. -The combination of Eiffel techniques and libraries yields a very simple approach to building and processing abstract syntax trees. Class [[ref:/libraries/parse/reference/construct_chart|CONSTRUCT]] is a descendant of the Data Structure Library class [[ref:/libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] , describing a versatile implementation of trees; so, as a consequence, are [[ref:/libraries/parse/reference/construct_chart|CONSTRUCT's]] own descendants. The effect of parsing any specimen of a construct is therefore to create an instance of the corresponding construct class. This instance is (among other things) a tree node, and is automatically inserted at its right place in the abstract syntax tree. +The combination of Eiffel techniques and libraries yields a very simple approach to building and processing abstract syntax trees. Class [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] is a descendant of the Data Structure Library class [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] , describing a versatile implementation of trees; so, as a consequence, are [[ref:libraries/parse/reference/construct_chart|CONSTRUCT's]] own descendants. The effect of parsing any specimen of a construct is therefore to create an instance of the corresponding construct class. This instance is (among other things) a tree node, and is automatically inserted at its right place in the abstract syntax tree. -As noted in the discussion of trees, class [[ref:/libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] makes no formal distinction between the notions of tree and tree node. So you may identify the abstract syntax tree with the object (instance of [[ref:/libraries/parse/reference/construct_chart|CONSTRUCT]] ) representing the topmost construct specimen in the structure of the document being analyzed. +As noted in the discussion of trees, class [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] makes no formal distinction between the notions of tree and tree node. So you may identify the abstract syntax tree with the object (instance of [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] ) representing the topmost construct specimen in the structure of the document being analyzed. ===The production function=== @@ -200,9 +200,9 @@ A construct class describes the syntax of a given construct through a function c end -Function production remains deferred in classes [[ref:/libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:/libraries/parse/reference/choice_chart|CHOICE]] and [[ref:/libraries/parse/reference/repetition_chart|REPETITION]] . Every effective construct class that you write must provide an effecting of that function. It is important for the efficiency of the parsing process that every effective version of production be a once function. Several examples of such effectings are given below. +Function production remains deferred in classes [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:libraries/parse/reference/choice_chart|CHOICE]] and [[ref:libraries/parse/reference/repetition_chart|REPETITION]] . Every effective construct class that you write must provide an effecting of that function. It is important for the efficiency of the parsing process that every effective version of production be a once function. Several examples of such effectings are given below. -Classes [[ref:/libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:/libraries/parse/reference/choice_chart|CHOICE]] , [[ref:/libraries/parse/reference/repetition_chart|REPETITION]] and [[ref:/libraries/parse/reference/terminal_chart|TERMINAL]] also have a deferred function construct_name of type STRING, useful for tracing and debugging. This function should be effected in every construct class to return the string name of the construct, such as "INSTRUCTION" or "CLASS" for construct classes in a grammar of Eiffel. For efficiency reasons, the construct_name function should also be a once function. The form of such a function will always be the same, as illustrated by the following example which may appear in the construct class INSTRUCTION in a processor for Eiffel: +Classes [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:libraries/parse/reference/choice_chart|CHOICE]] , [[ref:libraries/parse/reference/repetition_chart|REPETITION]] and [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] also have a deferred function construct_name of type STRING, useful for tracing and debugging. This function should be effected in every construct class to return the string name of the construct, such as "INSTRUCTION" or "CLASS" for construct classes in a grammar of Eiffel. For efficiency reasons, the construct_name function should also be a once function. The form of such a function will always be the same, as illustrated by the following example which may appear in the construct class INSTRUCTION in a processor for Eiffel: construct_name: STRING -- Symbolic name of the construct @@ -217,7 +217,7 @@ The examples of the next few sections, which explain how to write construct clas Having studied the EiffelParse library principles, let us see how to write grammar productions for various kinds of construct. The main task is to write the production function for each construct class. -The production function for a descendant of [[ref:/libraries/parse/reference/aggregate_chart|AGGREGATE]] will describe how to build a specimen of the corresponding function from a sequence of specimens of each of the constituent constructs. Writing this function from the corresponding production is straightforward. +The production function for a descendant of [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] will describe how to build a specimen of the corresponding function from a sequence of specimens of each of the constituent constructs. Writing this function from the corresponding production is straightforward. As an example, consider the production function of class LINE for the Polynomial example language. The corresponding production is
@@ -321,7 +321,7 @@ Then for each alternative component represented by a local entity component (in ===Repetitions=== -The production function for a descendant of [[ref:/libraries/parse/reference/repetition_chart|REPETITION]] will describe how to build a specimen of the corresponding function as a sequence or zero or more (or, depending on the grammar, one or more) specimens of the base construct. The class must also effect a feature separator of type STRING, usually as a constant attribute. (This feature is introduced as deferred in class [[ref:/libraries/parse/reference/repetition_chart|REPETITION]] .) +The production function for a descendant of [[ref:libraries/parse/reference/repetition_chart|REPETITION]] will describe how to build a specimen of the corresponding function as a sequence or zero or more (or, depending on the grammar, one or more) specimens of the base construct. The class must also effect a feature separator of type STRING, usually as a constant attribute. (This feature is introduced as deferred in class [[ref:libraries/parse/reference/repetition_chart|REPETITION]] .) As an example, consider the construct Variables in the Polynomial example language. The right-hand side of the corresponding production is
@@ -363,7 +363,7 @@ Lexical interface classes usually follow a common pattern. To take advantage of L_INTERFACE is a simple deferred class, with a deferred procedure obtain_analyzer. It is an heir of METALEX. ===Obtaining a lexical analyzer=== -An effective descendant of [[ref:/libraries/parse/reference/l_interface_chart|L_INTERFACE]] must define procedure obtain_analyzer so that it records into the lexical analyzer the regular expressions and keywords of the language at hand. In writing obtain_analyzer you may use any one of three different techniques, each of which may be the most convenient depending on the precise context, to obtain the required lexical analyzer: +An effective descendant of [[ref:libraries/parse/reference/l_interface_chart|L_INTERFACE]] must define procedure obtain_analyzer so that it records into the lexical analyzer the regular expressions and keywords of the language at hand. In writing obtain_analyzer you may use any one of three different techniques, each of which may be the most convenient depending on the precise context, to obtain the required lexical analyzer: * You may build the lexical analyzer by defining its regular expressions one by one, using the procedures described in the presentation of METALEX, in particular put_expression and put_keyword. * You may use use procedure retrieve_analyzer from METALEX to retrieve an analyzer which a previous session saved into a file. * Finally, you may write a lexical grammar file (or reuse an existing one) and process it on the spot by using procedure read_grammar from METALEX. @@ -670,7 +670,7 @@ The call build ( document takes care of steps [[#step_e1|1]] and
where set_input_file, from class INPUT, has a self-explanatory effect. -Finally, step [[#step_e4|4]] (processing the document) is simply a call to procedure process, obtained from [[ref:/libraries/parse/reference/construct_chart|CONSTRUCT]] . Recall that this procedure simply executes
+Finally, step [[#step_e4|4]] (processing the document) is simply a call to procedure process, obtained from [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] . Recall that this procedure simply executes
parse if parsed then diff --git a/documentation/trunk/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki b/documentation/trunk/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki index fe75e8aa..f2e668e7 100644 --- a/documentation/trunk/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki +++ b/documentation/trunk/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki @@ -42,7 +42,7 @@ The information the server sends back may be confidential. Follow these steps to ===Complex Headers=== -The Eiffel-Web application has the possibility to send a selection of different HTTP headers. They can be found in class CGI_RESPONSE_HEADER. In particular, it is advised to generate a status for each request, the value of the most common ones may be found in class [[ref:/libraries/web/reference/cgi_common_status_types_chart|CGI_COMMON_STATUS_TYPES]] . +The Eiffel-Web application has the possibility to send a selection of different HTTP headers. They can be found in class CGI_RESPONSE_HEADER. In particular, it is advised to generate a status for each request, the value of the most common ones may be found in class [[ref:libraries/web/reference/cgi_common_status_types_chart|CGI_COMMON_STATUS_TYPES]] . ===Debugging facilities===