[Development] Common base class for all socket types

[d3fault]

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