Re: GLib/GObject/Pango structure review

[Tim Janik <timj gtk org>]

On Sat, 23 Feb 2002, Owen Taylor wrote:

> GLib:
> 
>   GHook

won't grow, there're size restrictions on this one.
(if at all, i'd rather have this shrink by merging flags
with refcount or something the like ;)

>   GHookList

should have padding pointers (say 2) to be save, but
changes aren't planned.

>   GMemVTable

this will definitely not change as long as we're source
compatible. we've had enough discussions on whether to extend
this or not, and in the end went with the least common denominator
that is decently usable.

>   GScannerConfig

this is probably only to gain more flags in the future, so
adding another guint will allow for plenty of flags to be added.

>   GThread

i'm not sure adding more public members to this would actually
make sense, but in the end, it's sebastians call.

>   GThreadFunctions
>   GDebugKey

what (possible) change can you imagine here? i think the API
should really stay as lean as it is.

> GObject:
> 
>   GClosure

isn't going to grow at least until the next source incompatible
release, and even then, growing closures will be unlikely as it's
current small size is one of its main design aspects.

>   GEnumValue
>   GFlagsValue

will both not change.

>   GParamSpecTypeInfo

i do not envision this to change, this is convenience API
anyways, so if there was a desire to change this, we'll either
wait until the next source incompat release or simply add another
convenience call.

>   GInterfaceInfo
>   GTypeFundamentalInfo
>   GTypeInfo

these are unlikely to change, most languages don't
change their object system on a day-to-day basis ;)
however, forseeable is the possibility of s/n_preallocs/unused/
in GTypeInfo at some point. i don't see a requirement for padding.

>   GTypeValueTable

tentative change: adding an lcopy_value() variant that moves
the value contents from a GValue to an location pointer. i'm not
sure that is a good idea though, and requiring all value type
implementations to change will be a pain. so i'm ok with not
padding this.

>   GTypeInterface

this is as likely to change as GTypeClass or GTypeInstance ;)
i.e. highly unlikely to change.

>   GTypeQuery

i'm pretty uncomfortable with extending this, all the interesting
bits about types are already exported in one way or another.

>   GSignalQuery

unlikely to change because we already expose every bit about signals
that's meaningfully to be exposed.

>   GEnumClass
>   GFlagsClass

i can't really forsee a reasonable change here that'd justify
extension.

>   GParamSpecClass

adding 2 or 4 function pointers here wouldn't hurt too much,
though i don't have any extensions in mind at this point, there
might popup feature requests for param specs that'll
be reasonably justified and require extensions.


---
ciaoTJ