[Development] Common base class for all socket types

[Corentin Jabot]

The following seems like a good subset of the QAbstractSocket
interfaces that also makes sense for QLocalSocket

void abort ()
void disconnectFromHost ()
SocketError error () const
bool flush ()
bool isValid () const
qint64 readBufferSize () const
void setReadBufferSize ( qint64 size )
bool setSocketDescriptor ( int socketDescriptor, SocketState
socketState = ConnectedState, OpenMode openMode = ReadWrite )
int socketDescriptor () const
SocketType socketType () const
SocketState state () const
bool waitForConnected ( int msecs = 30000 )
bool waitForDisconnected ( int msecs = 30000 )

The SocketError & SocketState enums have already similar values in both class

SocketType should be in TcpSocket, UdpSocket, LocalSocket - ( could
also be NamedPipeSocket ? )

The following signals could also be common (again, it's about using
the same enums):
void connected ()
void disconnected ()
void error ( QAbstractSocket::SocketError socketError )
void stateChanged ( QAbstractSocket::SocketState socketState )

I dont see how the connectTo* methods could be shared, and I don't
think it would be a good idea to try to do so.

Regards,
Corentin.


2012/11/6 Thiago Macieira <thiago.macieira at intel.com>:
> On terça-feira, 6 de novembro de 2012 11.49.40, Alfonso Chartier wrote:
>> Someone below asked what the motivation is behind having a common abstract
>> socket base class for all concrete socket types. The reason for this is it
>> can significantly clean up client code. Currently if I want to handle
>> different sockets generically (e.g., TCP vs. local), I have to jump through
>> several hurdles: create my own wrapper class abstraction, maintain separate
>> lists of objects, etc. A single, common base class would allow client code
>> to use polymorphism to manage and use socket objects very easily. For
>> instance, I could then have client code that defines a
>> QList<QAbstractSocket*> and is able to connect, disconnect, write, read,
>> etc. from the socket without having to know the concrete class type.
>>
>> I hope this helps explain why it would be very useful to have a common base
>> socket class.
>
> It's very clear why you'd want to have a common base class, but you were not
> concrete on the details. I want to know what methods from QAbstractSocket
> and/or QLocalSocket would you like to see in this common base class, methods
> that aren't in QIODevice.
>
> Or, asked from another angle: why you can't use QList<QIODevice *> in your
> case above? You said disconnect, read, write, all of which you can do with
> QIODevice (close() is virtual, the signals are in QIODevice).
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>