Re: TextRider bug on last token

[Ian Rae <ianrae@istar.ca>]

> IR> 1.  There appears to be a bug in TextRider.ReadLInt().  If the
> integer
> <snip>
> 
> TextRider.Mod is in subdirectory lib, and the module's source code is
> also installed in the installation directory (in <prefix>/oo2c/lib/).

My tar file was corrupted -- no lib subdirectory.  I'll try again.

> 
> The problem is related to the lookahead by one character implemented
> by TextRider.  When backing up one char, the error code needs to be
> backed up, too.  I will look into this.

Thanks.
 
> IR> 2. A small change request for Channel.Mod.  Please add the
> following field:
> IR> 
> IR> eolType-: INTEGER;
> IR> (* Type of end-of-line char(s) this channel has.
> IR> 0=lf, 1=cr/lf, 2=cr.
> IR> *)
> 
> I am sorry, but this is not possible.  A channel is defined as a
> sequence of uninterpreted bytes.  It has no concept of "lines", nor
> of
> "end of line" characters.  The same is true for all implementations
> of
> Channel and all binary riders.  Therefore I cannot introduce this
> alien concept at this level.
> 
> The field must be made an attribute of text riders.

I was more interested in keeping TextRider generic (i.e. not caring
about the type of Channel it's connected to).   You're right that
eolType doesn't really belong in Channel.  I'll find another way.
 
> IR>    This is necessary because my portable text i/o library
> supports
> IR> several types of channels.  The BBox implementation supports
> Files and
> IR> Texts (the Bbox text object).  These have different eol
> characters:
> IR> cr/lf and cr respectively.
> 
> These are not different types of channels, but rather different
> interpretations of them, at least in the frame of definitions used by
> the OOC lib.  Bbox might see this differently.  On the other hand,
> OOC's IO libs were mostly inspired by Oberon/F, so I would be very
> surprised if they broke their own layering concept.

They are different types of channels as far as I can see.  OttFiles 
is a connection to a native OS file (Mac or Win95), and OttText 
is a connection to a Bbox Text object which may or may not be 
stored in a file. The current TextRider handles eol issues on a per 
platform basis, which isn't flexible enough in this case.
On Win95 at least, one could conceivably have channel types
for files, ActiveX components, controls (eg. edit boxes), and
Bbox Text objects.  They all could use different eol characters.

I'm quite happy to change TextRider.ConnectReader to query the
channel type and set eol characteristics.  But there's a larger
design issue of how riders are aware of channel semantics.
The following is more musing than actually proposing a wholesale
change.
Riders should (in the ultimate sense) be abstract classes.
Take a BitmapRider that scanned for pixels in various bitmaps.
This should be an abstract class with concrete implementations
for riding TIFF data sources, JPEG data sources,etc.
Like a channel, once one has a BitmapRider one no longer 
needs to know or care what underlying bitmap format is being
used.
Similarly a BboxTextRider and OSTextRider would be
concrete classes of TextRider.


--Ian