[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New TextRider & oo2c patch
Michael van Acken wrote:
>
> Here is my proposal of the eol implementation, based on recent
> postings on this mailing list:
[snip]
Maybe it's just me... but this really seems to be overkill. There isn't
really anything wrong with the proposal, except that it seems to me that
this degree of control is only useful under very limited circumstances. Is
there any other language/development-system/environment that gives this
degree of control over ReadLine and WriteLine type methods?
Allow me to digress into Java (that some claim is the ultimate in
portability):
Reading of entire lines of "text" is only allowed by the `BufferedReader'
through method `readLine()', which is defined to
Read a line of text. A line is considered to be terminated by any one of
a line feed ('\n'), a carriage return ('\r'), or a carriage return
followed immediately by a linefeed.
Returns: A String containing the contents of the line, not including
any line-termination characters, or null if the end of the stream has
been reached.
There is no way to change this to consider any other character(s) as a line
terminator. And why would you want to? If it's any other character(s),
then it's not *really* the end of a line, and you should use other means to
parse out your data.
As far as writing goes, entire lines of text are written out in only two
places (AFAIK), `BufferedWriter' and `PrintWriter' (System.out is a
predefined instance of PrintWriter).
BufferedWriter has a `newLine()' method, "which uses the platform's own
notion of line separator as defined by the system property
line.separator. Not all platforms use the newline character ('\n') to
terminate lines. Calling this method to terminate each output line is
therefore preferred to writing a newline character directly."
PrintWriter has overloaded `println()' methods that print out some type of
data, and then "finish the line." The docs go on to state that "the
println() methods use the platform's own notion of line separator rather
than the newline character."
Again, this is a system property, and can't be changed on-the-fly, or on a
per object/Writer basis. And why would you want to? If you want to write
out some special delimiting characters, you can just write them out
yourself (as in OOC using the `WriteChar' method).
So, when would you need the type of control as outlined by MvA? The
original request was as follows:
: 2. A small change request for Channel.Mod. Please add the following field:
:
: eolType-: INTEGER;
: (* Type of end-of-line char(s) this channel has.
: 0=lf, 1=cr/lf, 2=cr.
: *)
:
: This is necessary because my portable text i/o library supports several
: types of channels. The BBox implementation supports Files and Texts (the
: Bbox text object). These have different eol characters: cr/lf and cr
: respectively. TextRider needs to be able to sense and generate eol chars
: for any Channel. There is no other place to put this information except
: Channel.Mod.
Apparently, BBox isn't consistent about how it handles end-of-line. Isn't
there any other way to handle this special situation?
Under what other circumstances, when you're talking about any one platform,
do you need to be able to change the line terminator on-the-fly? Or change
the line terminator per each instance of Writer?
Eric