On Thursday 05 January 2012 22:21:54 Richard Moore wrote: > 2012/1/5 David Faure <david.fa...@kdab.com>: > > Solution 2: how about making this functionality part of QFile itself? > > No need to "port to another class" anymore, just enable the safety feature > > by calling file.setUseTemporaryFile(true). > > This is what I've started doing in the attached patch, but I'd like to > > gather feedback before polishing it up. > > One issue is that after doing file.setUseTemporaryFile(true) and > > file.open(), all the operations on the file object are no longer > > operating on the given fileName, but on the "internal" temporary file. > > That's what we want for writing, but maybe it could confuse people that > > remove() or rename() leaves the existing file untouched? I think it would > > simply have to be documented: when enabling the feature, all that happens > > between open() and close(), happens on the temp file. > > > > The other question is, would one have to call commit/rollback explicitely, > > or should QFile::close() (and the dtor) do the committing? > > And how should one rollback? Explicit file.rollback(), or in the existing > > file.remove()? > > Oswald suggested doing that in close()/remove() directly, and getting rid > > of commit()/rollback(). Opinions? > > I think this would be a great feature to have. In general I think > having it so that the commit is implicit makes more sense, but there > should be a way for the application to back out. I wonder if we should > have a concept like abort(), with things running open(), write(), /* > problem! */, abort() to address this.
Yes, your abort is what I called rollback. (My earlier discussion with ossi concluded that the name abort is too reminiscent of ::abort which stops the program). But the question is if it would be enough (and intuitive enough) to do it like this: file.setUseTemporaryFile(true) file.open() file.write() /*problem!*/ file.remove() And that will set a flag internally so that the dtor knows it shouldn't do anything. -- 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
