[Scummvm-devel] Re: FilesystemNode specs

[Marcus Comstedt]

Max Horn <max at quendi.de> writes:

> But if we keep the isDirectory(), then it would be strange to have
> the asymmetry between the listDir and the getChild case: For listDir,
> you can "ask" the return objects whether they are a file or a
> directory. For getChild, you should be able to do that, too, me
> thinks. Else we end up in a situation were you can or cannot use a
> method of an object reliably, based on how it was created -- which is
> very bad if one wants to pass around the object (code you call has no
> way of knowing how you obtained the node, after all).

If you by "reliably" means "without checking for errors", then you
can't have that anyway.  Even if you check, at object creation time,
that the node exists and is a file, it might not be by the time you
call open().  Someone might have erased it, or there could be a read
error etc.  So you need to be robust and check for errors anyway.
isDirectory() would return whether the node is _supposed_ to be
a directory or not.

Of course, another possibility would be to can isDirectory(), and
have listDir() return pairs of booleans and filesystemnodes instead,
to provide this information "out of band", so to speak.  But I think
that would be a clumsier approach.


> I hope this agrees with your thoughts, Marcus. If I understand you
> correctly, you are essentially opting for isValid being removed, but
> isDirectory (and a hypothetical isFile) could be kept, although it
> might "true" for non-existing nodes... I.e. code would be able to
> check whether a node, under the assumption the object it refers to
> exists, would refer to a file, or a directory. But to determine
> whether the node points to an actual existing filesystem object, one
> has to invoke File::open resp. listDir.

My take is this:  If you intend to use it, you need to call
open/listDir anyway. And nothing you do before that can guarantee that
open/listDir will succeed.  So it's pointless to try to.

And again, isDirectory() would indicate the intention of the object.
If it is true for a non-existing node, is is because it's a
non-existing _directory_.  I.e. it is a directory that you expected to
be there, but actually isn't.  In the same way it might be true for
something which you expected to be a directory, but which is actually
a file.  In both cases, you don't get what you expected and need to do
some error management.  In neither case would you be happier to get a
valid filesystem node for a file, as that is not what you
wanted/expected.


  // Marcus