On Friday 06 January 2012 10:24:04 craig.sc...@csiro.au wrote: > I like the idea that if nothing goes wrong, then close() commits the changes > (ie renames the temporary file to the real file name). It makes using a > QFile with this feature very transparent and means that functions that > accept a QFile will continue to behave in the way they did previously > regardless of whether or not this feature was enabled for a given QFile > instance.
This is an excellent point, I'm convinced now. > If something goes wrong during the write and you want to discard the file > contents you've written out so far, remove() doesn't seem to convey that > concept. I would prefer to see a function name that makes things clearer, > such as discardChanges() or similar. Excellent point too. Much clearer indeed. Yay, I love this. Note that remove() would still work, too: if it removes the temp file, then it also means discarding any changes. But that would be a side effect, discardChanges() would be the proper API for doing it. Now there's just one question remaining: even if the rule is that all operations apply to the temp file, between open and close... what should QFile::fileName() return? The temp file name, to obey that rule, or the target file name, for symmetry with setFileName()? I'm tempted to say: the latter, because the temp file is really internal, and to prevent surprises (breaking symmetry with setFileName). Of course it means file.remove() won't be the same as QFile::remove(file.fileName()) anymore... :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
