GLib/GObject+C as the lingua franca?
thiago at kde.org
Wed Jul 30 07:29:07 BST 2008
>> 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
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) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel