1,079
edits
Difference between revisions of "TODO"
→Files
(→Files) |
(→Files) |
||
| Line 94: | Line 94: | ||
* 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. 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. | ||
* 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()). | * 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). | |||
* Don't rely on the existence of SEEK_CUR, SEEK_END, SEEK_SET -- rather, define our own enum for this and convert all client code to use it. | * Don't rely on the existence of SEEK_CUR, SEEK_END, SEEK_SET -- rather, define our own enum for this and convert all client code to use it. | ||
* Try to replace all usages of paths by FilesystemNode. In particular, Engine::_gameDataPath and File::addDefaultDirectory() will have to be adjusted. The idea behind this is to ease portability. | * Try to replace all usages of paths by FilesystemNode. In particular, Engine::_gameDataPath and File::addDefaultDirectory() will have to be adjusted. The idea behind this is to ease portability. | ||