[Development] QFile: writing via a temporary file

[João Abecasis]

On 6. jan. 2012, at 22.09, ext Thiago Macieira wrote:
>> Why would this be better? It can't be "because it's not clear which file
>> some methods should work on" (Joao's argument), since it would still have
>> all the QFile methods. It can't be because we need additional API compared
>> to QFile, or is it, for one single rollback method? ;)
> 
> QTemporaryFile derives from QFile. I think a QSaveFile is the same as a 
> QTemporaryFile, except it's not temporary: when you close it, instead of it 
> going "poof!", it gets made permanent.
> 
> The code that does the writing doesn't need to know that it's operating on a 
> regular QFile, a QTemporaryFile or a QSaveFile.

QTemporaryFile is a bad example, in my opinion. In a couple of places we had to patch QTemporaryFile and QFile to maintain the QTemporaryFile abstraction because that is still a QFile...

I think part of the problem is that QFile is more than a QIODevice. It would help if it *didn't* have all the open methods, and the file operations, rename, remove, (set)Permissions, link and symLinkTarget. Open could live elsewhere and return a QFile/QIODevice that you interacted with for reading and writing, in which case you wouldn't need close either or to support operations on a closed QFile; one would close by calling the destructor/deleting the instance.

For QTemporaryFile, rename, remove and (set)Permissions may make some sense, but using them means you lose the guarantees offered by QTemporaryFile. The open methods in QFile don't make sense in QTemporaryFile.

For something like QSaveFile, none of those extra members in QFile make sense, in my opinion, because using them breaks the functionality that QSaveFile is trying to offer.

This mix of concepts that propagates to the file engines is part of the reason file engines are so horrible -- but that's another story entirely and that reminds me that they need to go private in Qt 5...

Cheers,


João