Op 28-7-2012 11:04, d3fault schreef: > > I've been thinking about it some more, and I think it would be a good > idea to add another optional bool to the opt-in custom interface > constructor. > Having (series of) bools in API's is usually a bad idea. See for instance this blog posting: http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html > > So it now would be: > QFileSystemWatcher(IQFileSystemWatcherSpecialCoarseToFineGrainedNotificationsFigureOuter > > *userCustomSnapshotComparisonCode, bool > alwaysUseCustomFigureOuterEvenIfPlatformDoesntNeedIt = false, QObject > *parent = 0); > > The reason for the additional bool is that we cannot predict what > criteria a _user_ will use to determine a file changed. They may > ignore certain changes that the native platform would emit, which will > lead to inconsistencies in their application on platforms with native > support vs. those without. The bool allows them to opt to take control > of every platform so there aren't any inconsistencies. It defaults to > false because most of the time the user will want to use the much more > efficient native platform notifications when available. > > We need a pretty beefy class description explaining all this. > That's exactly the problem.
In my view, these things should not be needed in the constructor at all. Instead, make the whole thing property based. That is: make the user-class that you plug into the QFileSystemWatcher something that you can just get and set. There are other examples of this in the Qt API, for instance in working with delegates in itemviews. By default, there will be a delegate set on an item view, but you can set your own if you want. The same goes for QItemSelectionModel: an instance is created by default, but you can just set another one if you want. The benefit is that: 1) it is all very explicit in the code. It is easy to understand what happens 2) it does not get in the way of those not using it 3) it allows initializing in any order that makes sense to the user It would be nice if the system default object doing the work, if there is such a thing, would be available from the API and you could "get" it from the QFileSytemModel. That would make it possible to use the default implementation from the custom one. So, instead of complicated constructors, I'd suggest some normal API methods instead: //say, QAbstractFileSystemBuffer is the class (interface) that takes care of tracking the file system changes void setFileSystemBuffer(QAbstractFileSystemBuffer* buffer); // QFileSystemModel takes ownership QAbstractFileSystemBuffer* getFileSystemBuffer(); // simply returns a pointer to the object QAbstractFileSystemBuffer* takeFileSystemBuffer(); // releases ownership of the object That makes this possible: QFileSystemWatcher* watcher = new QFileSystemWatcher(this); // MyFileSystemBuffer can use the standard implementation to do much of the work... MyFileSystemBuffer* buffer = new MyFileSystemBuffer(watcher->takeFileSystemBuffer()); watcher->setFileSystemBuffer(buffer); //watcher takes ownership of the buffer André _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development