On Tue, Sep 27, 2011 at 10:14 PM, Olli Salli <[email protected]> wrote: >> Do you think we need a similar struct for the source address pair (key >> of these mappings) too? IMO, that wouldn't make code looking up stuff >> from these mappings any cleaner though, as you can already see from an >> address and port being passed what those pair members are, so I guess >> this is more beneficial for the mapping value types. >> > > Actually we even couldn't do this consistently, because we already use > QPair<QHostAddress, quint16> in return types in many places in released > (Outgoing)StreamTubeChannel APIs, and PendingStreamTubeConnection. To be > consistent, we'd need to change those return types too, but we can't > because we need to preserve ABI compat there. > > Also, it'd be weird to define a type for a pair of host address + port, > as that's in no way a Telepathy specific concept. I rather think > QtNetwork should include one, as a host address and a port are seldom > useful alone - this type could be something like QDateTime, which > combines a QDate with a QTime. >
I think QPair is fine there. I agree that there could be a better class in Qt, but QPair will do for our API. Regards, George _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
