Some API comments and questions

[nerochiaro]

> > > > 1) Files get opened in the constructor and get closed in the
> > > > destructor. While this is fine for C++ use, it does become
> > > > inconvenient when used from languages that rely on garbage collection.
> > >
> > > Why not just use a proxy object?  i.e. Just create a class with the File
> > > methods and wrap those with (just using C++ here since I don't know
> > > Ruby):
> >
> > I'm not sure I explained the problem correctly.
> > The problem is not checking if a file is closed, the problem is that a
> > lot of times there is need for the file to be closed _immediately_, in
> > a very specific point in the program.
> > That's why I say that having a method to _explicitly_ close the file
> > would be useful.
>
> Right -- but if you're using a proxy class you can easily simulate the effects
> of a close.  You might even have to write that class in C++ -- I don't know
> enough about Ruby to know how the mapping from Ruby to C++ objects would
> work.
>
> Adding to the example above, then you would have a close method like:
>
> void RubyFile::close() { delete theRealFile; theRealFile = 0; }
> bool RubyFile::closed() const { return theRealFile == 0; }
>
> Does that make more sense?

Yes, this will work.
However it still feels like a bit of a waste to me to write a proxy
class that has to wrap all the File methods calling the real ones
underneath just to get that close method.
But it's not a big problem of course and it will do just fine.

Just out of curiosity, was there a specific reason for not including
in the design an explicit close method aside of the destructor ?