There is a ton of overlap between QIODevice and QAbstractSocket, but don't think too hard about it or else you'll drive yourself mad.
The most common functionality that is shared between QAbstractSocket and QLocalSocket is just the connect/disconnect functionality. Aside from that, yes they are both more or less just QIODevices. Lots of things fit the QIODevice abstraction. With QAbstractSockets: aside from the contradiction that is UDP, you are connecting to a server, IO'ing to/from it, then disconnecting (udp emulates this). The IO stuff all exists in QIODevice already, so QAbstractSocket almost seems unnecessary. Yes QProcess and even QFile can be used to communicate with a 'server', but in general they are not. QNetworkReply, however, has no 'connectTo' analog so doesn't really fit at all. QNAM is a different networking model. I find it strange that QNetworkRequest doesn't also derive from QIODevice, but eh I don't really use QNAM all too often so I don't really care to think about it. With further analysis between the similarities of QIODevice/QAbstractSocket, I've changed my mind and now think that QAbstractDataChannel (as a replacement to QAbstractSocket) is a crappy base name. It's too ambiguous with QIODevice. So how about QAbstractConnectionStream instead to replace QAbstractSocket? Without providing concrete examples, changing the design to specify the connect parameters in the constructor provides an obvious benefit with zero cost. The old empty constructor remains, and so does the overloaded/helper connectTo with all the argument still there. This wouldn't even break the API if we didn't change the name (but we should). If you require concrete examples, think of any case that justifies the existence of the current QAbstractSocket. Why was it created? Why weren't QTcpSocket and QUdpSocket just derived straight from QIODevice? Your answer to that is the answer to 'provide concrete examples of why QLocalSocket should derive from QAbstractSocket instead of QIODevice'. It should also seem like common sense seeing as QLocalSocket has the word "socket" in it. All this chit-chat is worthless, but we should probably agree on a new base name at the very least. As for doing the same to QProcess's constructor: why not? Obvious gains, zero cost. QFile already has the filename optionally specifiable in the constructor :-), though it lacks an open(filename) overload (trivial to add). Is anybody working on this? I really wish I could (I would!) as it seems so trivial... but (brace for lulz) I need a PSU to boot up my desktop to have enough megabytes to clone/compile Qt 5. Fracking POS netbook. Christmas is just around the corner and I've been a good boy this year. I'm 12 and what is this. d3fault _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
