[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: GIO API review
From:       Michael Natterer <mitch () imendio ! com>
Date:       2007-12-13 13:50:34
Message-ID: 476138AA.1080503 () imendio ! com
[Download RAW message or body]

Alexander Larsson wrote:
> On Wed, 2007-12-12 at 16:46 +0100, Michael Natterer wrote:
>> Alexander Larsson wrote:
>>> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: 
>>>> Hey everybody,
>>>>
>>>> We've been doing a GIO API review in the last couple of days and
>>>> here is the list of comments and issues we've come up with:
>>>>
>>>>
>>>> General:
>>>> ========
>>>>
>>>> It seems GIO allows individual files to be included, this should be
>>>> avoided like gobject does it:
>>>>
>>>> #if !defined (__GLIB_GIO_H_INSIDE__) && !defined (GIO_COMPILATION)
>>>> #error "Only <gio.h> can be included directly."
>>>> #endif
>>> Why? I know gobject does this, but I never understood why. It seems to
>>> just make build times longer.
>> Because otherwise you get into the very same typedef and include mess
>> we have in glib and gtk+. It makes it *very* hard to change anything
>> type related in the future. Any addition of a new function that happens
>> to use a new type which was not used in that header before might work
>> fine for the library's build itdelf, but might break the build of
>> applications that include whatever combination of headers.
>>
>> Clear structure of headers and types should never be traded for compile
>> time, we also keep distinct things in distinct .c files. Why would we
>> scatter our typedefs across our libraries, or keep certain includes in
>> headers forever?
> 
> Ok. I guess this makes sense. I'll do this.

Thanks :-)

I forgot to mention, gobject has its common header in glib/. I'm not
quite sure about this decision and I'm also not sure if saying

#include <glib-io.h>

or

#include <gio/gio.h>

is the more "natural" thing to do... Just for consideration.

>> I would even argue that it makes most sense to keep all opaque typedefs
>> in one single file and include that from "gio.h" and from each source
>> file within GIO. This way you can avoid including any headers from
>> headers at all and it makes things so *very* much easier to maintain.
>> We changed all of GIMP to this policy a few years back and never had
>> a single (!!!) problem related to includes ever since.
> 
> I'm not sure this is all that much cleaner. But if we go with the one
> global header we can switch to this later as we please.

I agree it's indeed a bit fanatic, but with the one header approach
you are free to do it at any time, as you said.

ciao,
--mitch
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]