Some API comments and questions

[Scott Wheeler]

On Thursday 19 January 2006 10:16, nerochiaro wrote:
> > > 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):
> >
> > RubyFile::read()
> > {
> >   if(!closed())
> >     theRealFile->read(...);
> > }
>
> 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.
> In C++ you would say "delete my_file_obj" and the destructor would get
> called immediately and the file would be closed.
>
> Ruby can't do that because in Ruby you just say something like
> "my_file_obj = nil" which means "I'm not using my_file_obj" anymore -
> but that doesn't trigger the object destruction immediately at that
> point.
> You have to wait a random amount of time for the garbage collector to
> kick in and actually call delete on the object, and for all that
> random time the file remains open.
>
> 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?

-Scott

-- 
There are 10 types of people in the world: Those who understand binary, and 
those who don't.