Re: GIO API review

[Sven Herzberg <herzi gnome-de org>]

Alexander Larsson wrote:
> On Thu, 2007-12-13 at 14:50 +0100, Michael Natterer wrote:
>   
>> 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'm for <gio/gio.h>. It seems more inline with all our other libraries.
> Only gobject does the <glib-object.h> thing.
>   

Shouldn't <gio.h> be enough? This would really drop 4 letters that every
gio-using developer had to type and which are really redundant. I really
don't like this <foobar/foobar.h> style because it forces developers
just to type more than they IMHO should.

Regards,
  Sven