GLib/GObject+C as the lingua franca?

Thiago Macieira thiago at
Wed Jul 30 07:29:07 BST 2008

nf2 wrote:
>> But the current way Qt and KDE API is designed is that we divide
>> things into two main groups:
>>  - "value type" classes: they are implicit shared, detach atomically
>> on write, never used as pointers, never use QObject. Can be
>> implemented using QSharedData/QSharedDataPointer.
>>  - "object type" classes: cannot be copied, usually derive from
>> QObject, used both on the stack and as pointers to the heap.
>I wonder if i made a mistake when designing my API. Perhaps many of the
>async functions in my GFile and GInputStream wrappers
>shouldn't emit signals, but rather just take a slot as an argument?
>In this case - do i still need to derive my wrapper classes from
> QObject?

I haven't looked at the links.

But remember this: a value-type class usually simply holds information: 
QString, QRect, QNetworkCookie, for example, come to mind. They don't 
*do* anything, so they don't have signals, slots or callbacks.

Object-type classes, on the other hand, do. Signals generally include a 
verb in the past tense, actions are verbs in the imperative. These 
objects are not ref-counted and are not copiable.

If you were to copy an object that represents a file, it would not copy 
the file. The two objects would still represent the same file. Even if 
you allowed the two to write to different portions of the file, it's 
still a bad idea.
  Thiago Macieira  -  thiago (AT) - thiago (AT)
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list