Validate
||
Pedestal
Validated HTML 4.0
Pedestal's I/O subsystem is exemplary of the degree of modularity prescribed by the design goals. A supposedly simple operation such as reading a file involves no less than five distinct classes of objects (though only three are instantiated directly): First, the file is located using a file system reference (class PedFSRef). The reference is used to create a file data-source (class PedDataSourceFile), which creates a raw access path (PedAccessRaw) to the file. There are two kinds -- PedAccessData and PedAccessRF, for reading the data and resource forks respectively. (There's also PedAccessRes, which is for accessing resource files through the Resource Manager, and therefore can't be used for a data source.) A data source is simply that -- it's a source of data that is accessed a bufferfull (PedBuffer) at a time. Finally, an input stream (in this case a buffered input stream (PedStreamInputBuffered)) is created to draw from the data source (or if it's a text source, PedStreamInputBufferedText). An input stream of any kind (PedStreamInput) is read one byte at a time, at which point the application is free to do with it as it sees fit, possibly using a dispenser object (e.g. PedDispenserString) to package the data in some desireable form.
This is even more useful than it may at first appear. Simply by calling GetByte() on a buffered input stream (or using a dispenser, which will do the same thing), blocks of the file are read in and buffered as necessary, and those buffers are automatically deleted after their data have been read. But why is this any better than using the File Manager's built-in buffering?
The advantage of having such highly factored behavior becomes evident upon examining other possibilities for its use. A data source could be an HTTP stream instead of a file. One data source could be passed (through an input stream) to another one which compressed or decompressed it along the way. A special kind of access path could read the 'MacBinary' fork of a file (by internally reading both data and resource forks and performing the encoding). An input stream could return random bytes, null characters, or end-of-file (analogous to Unix's /dev/random, /dev/zero, and /dev/null respectively). In addition, the text input stream transparently converts newlines (the lack of which feature has caused no end of mischief).
An equally full-featured output system is in the works.