Provides "abilities". Those classes are best used via inheritance. They give extra functionality to a class.
The currently available abilities are:
COMPARABLEfor objects that can be compared between themselves;
HASHABLEfor objects that want to interact with the Garbage Collector when they are about to be collected;
HASHABLEfor objects that provide a hash code (e.g. useful for hashed dictionaries and sets);
OBSERVABLEfor objects that can notify observers when their state changes (that's the Observer Design Pattern);
RECYCLABLEfor objects that can be reused via a
STORABLEfor objects that want to be put on an external medium, to be retrieved again later;
TRAVERSABLEfor objects that provide traversal facilities;
VISITABLEfor objects that can be visited using the Visitor Design Pattern.
Provides some Design Patterns. Design Patterns were introduced mainly by the Gang of Four in their great book: Design Patterns -- Elements of Reusable Object-Oriented Software (E. Gamma et al.) We also use the book Design Patterns and Contracts (J.-M. Ézéquiel et al.)
The currently available Design Patterns are:
CHAIN_HANDLERthat can handle a request from the Chain;
PROCESS object starts an asynchronous process. The
standard streams of that process are redirected to the caller via three streams.
HTML is the HyperText Markup Language, defined with tags such as
This cluster contains two important classes:
When creating streams, one should procede as follows:
connect_tofeature of filter streams;
Taken together, interconnected filters and terminal make a filtered stream; one reads and/or writes from one side of the "pipe", while the terminal reads/writes at the other side.
Those classes are split in two hierarchies: on the one hand, filters, on the other hand, terminals.
Filtered streams are in fact a double-linked objects: each filter points to an underlying
stream (be it another filter or a terminal) while each stream points to a
filter. The "stream-to-filter" back-link is used for assertions, to ensure one does not bypass
Filters are stuck in front of a stream (be it another filter or a terminal). They provide extra functionality: compression, buffers, and so on.
Note: you cannot directly use streams that are connected to a filter; use that filter instead.
Terminals are back-end bytes readers and/or writers. There are many such terminals: files, sockets, strings
and so on. There are even the equivalent of the good old Unix
/dev/null device, which eats bytes
and provides zeroes.
Note that there are only terminal input-output streams. Filters do not have this notion: you use either an input or an output stream, even if the underlying resource has input-output capabilities.
STANDARD_STREAMS provides access to the
GENERAL provides an access to a
STANDARD_STREAMS once object, along with shortcuts to the most used features: the standard
std_error, and the most used
io which is but a centralized access to the former two.
STANDARD_STREAMS provides features to dynamically
change standard streams. It allows to:
The easiest way for reading characters on an input_stream is as follow:
from -- connect my_input_stream if needed here my_input_stream.read_character until my_input_stream.end_of_input loop -- use my_input_stream.last_character my_input_stream.read_character end my_input_stream.disconnect
The easiest way for reading lines on an input_stream is as follow:
from -- connect my_input_stream if needed here until my_input_stream.end_of_input loop my_input_stream.read_line if my_input_stream.end_of_input then -- The last line of the file does not end with a new line -- character. Remove this test if you don't care. -- use my_input_stream.last_string else -- use my_input_stream.last_string end end my_input_stream.disconnect
Whket), o rarymon ating M> < g MryTt system of/tutorial/d clatorating M> < g