GLib/GObject+C as the lingua franca?

[Thiago Macieira]

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
>
>http://library.gnome.org/devel/gio/stable/GFile.html#g-file-read-async
>http://library.gnome.org/devel/gio/stable/GInputStream.html#g-input-stre
>am-read-async
>
>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) 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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080730/ba75890f/attachment.sig>