[Scummvm-devel] PORTERS: Changed made to DefaultSaveFileManager

Max Horn max at quendi.de
Tue Aug 5 13:53:21 CEST 2008


Hi again,

I need to clarify something. I wrote this:


Am Di, 5.08.2008, 13:42, schrieb Max Horn:

[...]

> Ideally, all ports will run just fine with these changes. However, it
> uncovered a bug in the Windows implementation of FSNode::getChild()
> already. After some visual inspection, it seems that the PalmOS and
> Symbian ports are affected as well: Their getChild method returns 0 if
> the requested child node does not exist, but that makes it impossible
> to acquire a node for a file which does not yet exist but is about to
> be created. The correct implementation would be to return a node which
> returns false when it's exists() method is called.

Actually, these ports behave 100% correct in that they implement our
FSNode specification to the letter, which says for getChild():

* Returns the child node with the given name. If no child with this name
* exists, returns 0. When called on a non-directory node, it should
* handle this gracefully by returning 0.

SO, what I should have written: There is a *design flaw* in FSNode, and
those ports are affected because they did everything right and implement
the specs to the letter. So, in particular, it's not in anyway the "fault"
 of those porters that things break.

Why do I say this is a design flaw, as opposed to me screwing up the
DefaultSaveFileManager? (Well, maybe I did screw it up regardless, your
call :).
Well, my rationale is this: We have FSNode so that we don't have to deal
with paths directly. One frequent use for FSNodes is to traverse the
filesystem. You want to navigate to subdirs and parentdirs, and want to
exist files.
But you also want to be able to create new files in existing dirs.

I see two solutions to this:

1) Change the spec to allow getChild to be used on not-yet-existing
subnodes, makeing it possible to then create a file or directory for that
node.
2) provide a new method like createChild, resp. createFile/createDir.

Personally, I prefer (1). First, it is by far the quickest to implement
(mostly boils down to removing some code from getChild() implementations).
Secondly, I find it more natural, because for me FSNodes are the
equivalents of paths; and paths my be well-formed yet may not refer to an
existing file; the same holds for FSNodes.

So, before porters rush to make changes, we must settle this, fix the
docs, and *then* rush to make changes.

Cheers,
Max




More information about the Scummvm-devel mailing list