RE: Re: Re: When is File/Dir.exists?() false?

> > From: Mukhsein Johari
> > I'm feeling a bit uneasy about file and dir objects that 
> > don't refer to existing files and dirs. I can't put my finger
> > on why though. It just doesn't seem useful to me.

> From: Mark Hahn
> I'm sorry.  How else could I have the method "delete()" if
> an object could only exist when it's file system equivalent
> existed.  Don't forget that I'm attempting something new
> here.  Not even Java has a true object-oriented file system.

> > Could you show a simple use-case?

> I already did.  If you have an alternate idea for how to do 
> this, I'd love to hear it.  The one big stumbling block I'm 
> thinking of at this moment is what to do on Dir.delete().  
> The dir object cannot dissapear.  Only the garbage
> collector is allowed to make objects dissapear.

You don't have any choice about it. You have to allow your objects to
outlive the physical entities that they represent. Anybody could be holding
a reference to a Dir object when the directory is deleted.

In Acrobat multimedia JavaScript, we faced this same problem only worse. We
have a Player object that represents a running media player. You can close a
Player with player.close(), or the player may close on its own when it
reaches the end of playback. Either way, the actual media player is gone.

It didn't takes us long to realize that we couldn't just make the Player
object go away in this situation. Someone could still hold a reference to
the player--in fact we have "after" events that can fire after the player is
closed, and each of those event objects has a reference to the player.

So we just said that a Player object may or may not have an actual open
media player associated with it, and the player.isOpen property tells you
which.

-Mike