Difference between revisions of "TODO"

TODO (view source)

Revision as of 11:18, 26 February 2007

448 bytes removed , 11:18, 26 February 2007

Updated note on File::incRef/decRef

Fingolfin

1,079

edits

@@ Line 98: / Line 98: @@
 === Files ===
-* Get rid of the incRef/decRef API of class File. Instead, add a clone() method which generates a new (independant) File object for the same file (only would work for files in read mode, obviously). Convert the audio code to use this instead of the ref counting.<br> Reason: Using a shared file object can lead to race conditions if multiple threads try to use it at the same time; on some systems (Symbian) it is apparently not even possible to do it; iahd t can also cause problems even in non-threaded code, when we seek in one block of code, and then try to access it from another block, w/o reseeking first.
+* Get rid of the incRef/decRef API of class File. It used to be necessary for the Audio code, but that reason is gone and we now only use this API in about 4 spots.
 * Currently, FilesystemNode's default constructor invokes AbstractFilesystemNode::getRoot. There is no specified way to obtain the "current" directory (and indeed, on some systems, that notion doesn't even make sense). Thing is, currently, the browser uses this as its default starting location, which may not always be optimal. Still, it might be useful to add a AbstractFilesystemNode::getDefaultDir() method or so (on systems w/o a "current directory", it could just call through to getRoot()).
 * Method names in FilesystemNode are inconsistent: Compare getParent, getChild to displayName(), path(), and once again to listDir, isValid, isDirectory (of course this "problem" affects all of ScummVM to a degree). This is a typical clash of the "verb-object, verb-adjective" pattern (getParent, getPath, isValid) vs. the "pure object/adjective" pattern (parent, path, valid).

Difference between revisions of "TODO"

TODO (view source)

Revision as of 11:18, 26 February 2007

Navigation menu

Search