mweichselbaumer marked an inline comment as done. mweichselbaumer added inline comments.
INLINE COMMENTS > drosca wrote in a2dp-codecs.h:33 > Are you sure about this? Yes, this has also been fixed by bluez as of 2018-12-28. > drosca wrote in tpendingcall.h:45 > Is this really needed? In the end, it doesn't really make the code that much > better: > > TPendingCall<QDBusUnixFileDescriptor, uint16_t, uint16_t> *fd = > transport->tryAcquire(); > fd->valueAt<0>(); > fd->valueAt<1>(); > fd->valueAt<2>(); > > vs > > PendingCall *fd = transport->tryAcquire(); > fd->values().at(0).value<QDBusUnixFileDescriptor>(); > fd->values().at(1).value<uint16_t>(); > fd->values().at(2).value<uint16_t>(); > > Or we can add convenience method `T valueAt(int)` so it becomes: > > PendingCall *fd = transport->tryAcquire(); > fd->valueAt<QDBusUnixFileDescriptor>(0); > fd->valueAt<uint16_t>(1); > fd->valueAt<uint16_t>(2); Actually, my intention was to provide a type-safe way to obtain return values from PendingCall and to express explicitly, what the corresponding method returns in API header. As a client you can make use of "auto". Consider: auto *fd = transport->tryAcquire(); // Method declaration will define return type. auto ret1 = fd->valueAt<0>(); auto ret2 = fd->valueAt<1>(); auto ret3 = fd->valueAt<2>(); Thus, return type (of PendingCall) is expressed in API header and clients do not need to express the return types themselves. REPOSITORY R269 BluezQt REVISION DETAIL https://phabricator.kde.org/D22107 To: mweichselbaumer, drosca Cc: kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
