[Telepathy] tq-qt4 refcount proposal

[Simon McVittie]

Is there a Qt/KDE convention for this sort of thing, or are we in uncharted
territory here?

If there's no Qt/KDE convention, we should follow GObject's lead, since it's
a tried-and-tested refcounted object model that many of us have experience
with. In particular, we *will* need weak references in a number of places.

On Fri, 20 Mar 2009 at 17:50:23 -0300, Andre Moreira Magalhaes wrote:
> 2.1 - Problems:
> 2.1.1 - Circular dependency:
> In the ideal world we should use QExplicitlySharedDataPointer<Object> in 
> the library, even for objects that needs to know about each other, for 
> example StreamedMediaChannel that caches the MediaStreams and 
> MediaStreams that have a pointer to the StreamedMediaChannel. We should 
> be careful with this, as we hit circular dependency, which can lead to 
> even more memory leaks when the objects refcount never hits 0.

Tidying up circular dependencies when a natural end-of-life is reached
(invalidated signal) seems a reasonable approach; many Telepathy objects
(Channel, Connection) have such a thing.

Account and AccountManager might be tricky - there's no natural end-of-life
for the AccountManager, and Accounts' lives only end if the account is
deleted by the user (a rare event!). Perhaps Account could weakly ref the
AccountManager, and the AccountManager could strongly ref the Accounts?

(In practice, almost every UI will want to have a ref to the AccountManager
for the entire lifetime of the UI, I think, so the Accounts won't be GC'd
until later.)

> 2.1.3 - QObject parent relationship:
> All refcounted objects should not have a parent QObject, as when the 
> QObject gets deleted the children objects are deleted as well.

Right, the parent relationship bypasses the refcount. That's sad, but there's
not much we can do about that.

> 3 - Naming:
> So I propose to have a template class SharedPtr that inherits 
> QExplicitlySharedDataPointer, and a class named SharedData that is a 
> typedef for QSharedData (in case we want to change to use another class 
> in the future, we don't need to change all classes). We may want to make 
> SharedData call deleteLater on ref==0 instead of delete for example.
> 
> So the usage would be:
> 
> public Account : SharedData
> {
> public:
> ...
> static SharedPtr<Account> create();
> ...
> };

Do we really need to invent our own template class? Surely this problem has
been solved in Qt-land before‽

Can we have some arrangement where we have a typedef or trivial subclass called
AccountPtr, etc.? Otherwise, we'll have signals like

    accountValidityChanged(bool, Telepathy::SharedPtr<Telepathy::Client::Account>)

which is horrible! Using Telepathy::Client::AccountPtr is still quite verbose,
but I think it's the best we're going to get.

    S
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20090323/613fc0f7/attachment.pgp