Inheritance diagram for ConduitFilter:
Public Member Functions | |
uint | reader (void[] dst) |
uint | writer (void[] src) |
Protected Member Functions | |
void | bind (IConduit conduit, IConduitFilter next) |
void | unbind () |
final void | error (char[] msg) |
Protected Attributes | |
IConduitFilter | next |
The filter should return the number of bytes it has actually produced: less than or equal to the length of the provided array.
Filters are chained together such that the last filter added is the first one invoked. It is the responsibility of each filter to invoke the next link in the chain; for example:
class MungingFilter : ConduitFilter { int reader (void[] dst) { // read the next X bytes int count = next.reader (dst); // set everything to '*' ! dst[0..count] = '*'; // say how many we read return count; } int writer (void[] src) { byte[] tmp = new byte[src.length]; // set everything to '*' tmp = '*'; // write the munged output return next.writer (tmp); } }
Notice how this filter invokes the 'next' instance before munging the content ... the far end of the chain is where the original IConduit reader is attached, so it will get invoked eventually assuming each filter invokes 'next'. If the next reader fails it will return IConduit.Eof, as should your filter (or throw an IOException). From a client perspective, filters are attached like this:
FileConduit fc = new FileConduit (...); fc.attach (new ZipFilter); fc.attach (new MungingFilter);
Again, the last filter attached is the first one invoked when a block of content is actually read. Each filter has two additional methods that it may use to control behavior:
class ConduitFilter : IConduitFilter { protected IConduitFilter next; void bind (IConduit conduit, IConduitFilter next) { this.next = next; } void unbind () { } }
The first method is invoked when the filter is attached to a conduit, while the second is invoked just before the conduit is closed. Both of these may be overridden by the filter for whatever purpose desired.
Note that a conduit filter can choose to sidestep reading from the conduit (per the usual case), and produce its input from somewhere else entirely. This mechanism supports the notion of 'piping' between multiple conduits, or between a conduit and something else entirely; it's a bridging mechanism.
Definition at line 374 of file Conduit.d.
|
filter-specific reader Reimplemented from IConduitFilter. Reimplemented in EndianFilter. Definition at line 382 of file Conduit.d. References next, and IConduitFilter::reader(). Referenced by UnicodeFilter(). |
|
filter-specific writer Reimplemented from IConduitFilter. Reimplemented in EndianFilter. Definition at line 391 of file Conduit.d. References next, and IConduitFilter::writer(). Referenced by UnicodeFilter(). |
|
Reimplemented from IConduitFilter. |
|
Reimplemented from IConduitFilter. Definition at line 409 of file Conduit.d. References next, and IConduitFilter::unbind(). |
|
Definition at line 418 of file Conduit.d. Referenced by EndianFilter::reader(). |
|
|