[Scummvm-devel] File handling revamp

[Marcus Comstedt]

Max Horn <max at quendi.de> writes:

> FSNodes are only for data files (and maybe dump files, for writing),  
> they are *never* to be used for SaveFiles and ConfigFiles. That's one  
> of the major points driving my desire to revamp the file handling  
> business :).

And that's why I mention requirements for such a revamped version.
:-)  If we are to use FSNodes for more things (which seems logical,
since they provide the abstraction to "the filesystem"), they need to
know more.


> Sadly, I must have missed that suggestion or maybe did not understand  
> it correctly :/. So, do I get you right: You propose that instead of a  
> single FSNode class, we have say a FSDirNode and an FSFileNode class.  
> Then, you do:
>    FSDirNode dir("foo");
>    FSFileNode theFile = dir.getChild("bar.dat");

Yup.


> So, the main advantage of this would be that we kind of give the  
> FSNode constructor a flag which tells it whether we mean to refer to a  
> file, or a directory. Hm, I think I can see some merit to that, fully  
> agreed.

Also since FSDirNode would have no "filish" methods, and FSFileNode no
"directorish" methods, it improves the chance of finding mistakes
statically, something you would not get with a flag.


> Of course,
>    FSDirNode dir("foo");
> is more suggestive than
>    FSNode dir("foo", true);

Well, that particular problem can be solved with using an enum instead
of bool.  But I still think that restricting the set of callable
methods in the resulting object to those that actually have a chance
of working is preferable.  There can still be a common abstract
baseclass with things like getName(), and even isDirectory() if we
still want it, of course (could be useful in file browser UI code for
example).


> BTW, a mostly unrelated thing: I feel that it's bad that there is no  
> way to get back from an FSList to the corresponding FSNode; that is  
> useful when you want to e.g. print out a debug / error message. Like,  
> our detectors sometimes want to print a message like "Unknown game  
> version detected in dir FOOBAR", but with FSLists, they can't that.

Can't you just use getParent()?  Won't work if the list is empty of
course, but is that a problem?


>> but I figure that in the places you use it, you'd
>> typically want to separate the directories from the files anyway
>> (e.g. file browsers usually like to display all subdirectories
>> first).
>
> They can achieve *that* using a simple sort, so this is not really an  
> argument in my eyes, neither pro nor contra :).

Yes, I was merely arguing that the potential con probably wasn't a con
after all.  Not that it was a pro.  :-)


  // Marcus