Re: GLib/GObject/Pango structure review

[Tim Janik <timj gtk org>]

On Sat, 2 Mar 2002, Owen Taylor wrote:

> > 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.
> 
> We _can't_ pad structures like this, or like most other ones
> listed in my mail, because we have no way of knowing what
> fields in the field are value, so we'd have to introduce a
> requirement for zero intialization of the padding, which is
> a seriously incompatible API change.
> 
> My mail was mostly for reference purposes.

actually we can, and GScannerConfig is the prime example
for this, it relies on the implicit 0 initialization of
remaining fields of structures that compilers do since 1.0.
i agree that this is not always viable, but it is not an
issue for the structures where i suggested padding:

	>   GHookList

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

this one has it's own initialization function that can do the zeroing.

	>   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.

this one relies on implicit zeroing since 1.0.

	>   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.

this one is created by the type system which automatically zeros all
instances and classes it allocates.

> 
> Regards,
>                                         Owen
> 
> 

---
ciaoTJ