Seeing as how Ruby will return nil when an I/O stream is empty,
is there anything wrong with using nil where other languages might use EOF ?
As in this example:
File.open("text.txt") do |f|
puts f.gets(nil)
end
It isn't clear what you are asking. gets(nil) has a well-defined behavior
right now, it means to return the remaining data in the IO stream (i.e.,
until the end of file is encountered).
It sounds like you are thinking of EOF as an in-band but special character
value that marks the end of file. It is better to think of it as an
out-of-band sentinel value. In C, EOF is usually -1 and the associated
API specifies integer return values so that EOF is guaranteed to
never be confused with a valid in-band value.
In C, getc has to be defined to return an integer value so that
characters (0..255) and EOF (-1) are both statically valid but
can be differentiated. In Ruby, getc can return a fixnum or nil since
there is no need to statically define the return value of methods.
In C, gets returns a pointer to a string or NULL to indicate there is
no data (end of file has been reached). In Ruby gets returns a reference
to a string or nil when end of file has been reached.
I would be careful about thinking of nil and EOF (as in C) as
interchangeable. They serve similar purposes but the APIs and languages
are sufficiently different that I wouldn't push that analogy too far.
Gary Wright
···
On Apr 23, 2007, at 12:38 PM, John Joyce wrote:
Seeing as how Ruby will return nil when an I/O stream is empty,
is there anything wrong with using nil where other languages might use EOF ?
As in this example:File.open("text.txt") do |f|
puts f.gets(nil)
end
Thanks for the input. I hear you and already have the difference in my mind. Just that for those coming from other languages, especially the dive-in-with-only-online materials types, this might be a useful point.
I know what you mean already though, about EOF in Ruby. It's just that I've seen other posts where there was some confusion about that.
I guess I'm just wondering if using nil in this manner is indeed appropriate, or if there is some check or hole that needs performing. Coming from other languages this is often more of a concern. The way Ruby's objects work does a great deal to protect us from hosing things the way you can with C or C++ . Ruby certainly performs as I am often least surprised. (perhaps living in Japan for a long time does something to make Ruby make sense.)
···
On Apr 24, 2007, at 3:01 AM, Gary Wright wrote:
On Apr 23, 2007, at 12:38 PM, John Joyce wrote:
Seeing as how Ruby will return nil when an I/O stream is empty,
is there anything wrong with using nil where other languages might use EOF ?
As in this example:File.open("text.txt") do |f|
puts f.gets(nil)
endIt isn't clear what you are asking. gets(nil) has a well-defined behavior
right now, it means to return the remaining data in the IO stream (i.e.,
until the end of file is encountered).It sounds like you are thinking of EOF as an in-band but special character
value that marks the end of file. It is better to think of it as an
out-of-band sentinel value. In C, EOF is usually -1 and the associated
API specifies integer return values so that EOF is guaranteed to
never be confused with a valid in-band value.In C, getc has to be defined to return an integer value so that
characters (0..255) and EOF (-1) are both statically valid but
can be differentiated. In Ruby, getc can return a fixnum or nil since
there is no need to statically define the return value of methods.In C, gets returns a pointer to a string or NULL to indicate there is
no data (end of file has been reached). In Ruby gets returns a reference
to a string or nil when end of file has been reached.I would be careful about thinking of nil and EOF (as in C) as
interchangeable. They serve similar purposes but the APIs and languages
are sufficiently different that I wouldn't push that analogy too far.Gary Wright