[Scummvm-devel] Re: FilesystemNode specs

[Max Horn]

Another typical usage pattern not to be forgotten is this:

FSList files(dir.listDir(FilesystemNode::kListAll));
for (node in files) {
   if (node.isDirectory())
      ...
   else if (node.isfile())
      ...
}

So this usage relies on being able to tell whether a node represents  
a directory or a file. Of course we could use File::open / fopen here  
to do the test. But do we really want to open all files in a  
directory, just to be able to tell the files from the directories?  
That doesn't seem like a good / clean solution to me.

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

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.

Does that sound OK?


Cheers,
Max