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)
>> 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

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.)