On Mon, 2009-01-12 at 14:43 +0100, Jürg Billeter wrote:
> 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.
Nice!
> > > * 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.
Looked somewhat deeper into your proposal and see some issues when you
have a more complex source tree. Related to the build tools; how do you
see the use of "internal" across libtool convenience libraries? I think
it would be nice to access these internal apis, so you need a common
-priv.h file and inclusion in the .vapi file too.
In theory I guess we could mark those .vapi files as internal somehow
and even apply the same principles (declare directly into .c files). In
latter case the compiler probably would get overly complex and we lose
the autotools C dependency tracking mechanism, so I'm not sure if that's
even wanted though.
However, something like --library and --static-library, where you
automatically merge the statics and exclude the internals in the
generated .vapi file when --library is used. Might have missed some
essential blockers or design goals for this proposal, but what do you
think of it?
Regards,
Hans
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
