On Mon, 2009-01-12 at 08:40 +0100, Hans Vercammen wrote:
> On Sun, 2009-01-11 at 14:14 +0100, Jürg Billeter wrote:
> > * Internal API
> > The whole point of an internal API is that it is internal, and we
> > should therefore aim to separate public from internal header files.
>
> Yes, that sounds like a very good idea. Could we extend this with
> G_GNUC_INTERNAL somehow? Something like:
>
> public class Foo {
> internal void bar () {} /** Hide bar */
> }
>
> internal class Foo { /** Hide all methods */
> public void bar () {}
> }
>
> Or is there a different way to achieve the same thing.
Yes, we should definitively use G_GNUC_INTERNAL and your example is
exactly how it is supposed to work. internal will be default for
namespace members (as private namespace members are not supported), so
you will be able to skip `internal' for non-exported top-level classes.
> > * Minimize use of header files
> > A more radical approach would be to not use header files where not
> > necessary. The Vala compiler could insert required declarations at
> > the top of each generated .c file and only use include directives for
> > external libraries. This would lead to optimal rebuild performance at
> > the cost of a bit larger .c files.
>
> Not sure if I understand correctly but do you mean avoiding internal
> headers altogether? I think giving vala full control to decide which
> definitions/prototypes need to be declared in the individual .c files is
> probably the most easy and clean solution to overcome the header
> dependency hell. It might speed up the overall compile time too.
Yes, you understand it correctly, vala wouldn't use any internal header
files anymore. It will just include header files for external (C or
Vala) libraries, and it will generate a header file for the public API
when using -H.
> > We obviously still need to support generating header files to use
> > libraries written in Vala. I would propose to add an option -H foo.h
> > to valac to generate a single header file with the full public C API.
> >
> > I'm leaning towards the last solution as this solves all of the issues
> > mentioned above and should also provide the simplest way to integrate
> > into build systems such as automake. I can understand that some people
> > might not like that solution as it deviates from the traditional way how
> > you would do it in C. However, Vala is about practical solutions, not
> > traditions.
>
> I agree. The only case you need to dig into the generated .c files is
> when something is not working as it is supposed to do.
Thanks for your comments,
Jürg
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
