Re: [Vala] protected classes

["Juerg Billeter" <j bitron ch>]

On Wed, April 2, 2008 14:46, Vlad Grecescu wrote:
> Juerg Billeter wrote:
> > On Tue, March 4, 2008 17:16, Vlad Grecescu wrote:
> >
> > > Currently Vala uses
> > > - 'public' classes for classes that end up in the headers /and/ in the
> > > library (if you're building one)
> > > - 'private' classes for classes that don't end up in neither headers
> > > /nor/ in the created libraries.
> >
> > The idea is that 'private' (or 'internal') classes will end up in
> > private
> > header files. Top-level classes that are not in any header files (as the
> > situation is right now for 'private' classes) don't make any sense, as
> > we
> > don't want to support file-level accessibility in Vala.
> Ok, allow me to rephrase the idea - since the 'headers' talk was
> misleading.
>
> There will be libraries made with Vala. Those libraries will export all
> function symbols (thus, 'classes') by default, and will install all .h
> files by default.
> The libraries' authors will want to restrict the usage of the library to
> a certain API (ABI).
>
> This can currently be accomplished by providing a list of symbols for
> libtool - with either -export-symbols or -export-symbols-regex.
> The 'private' headers will be stripped from the installation by
> specifying noinst_ .
> Also, API documentation will be generated with either gtk-doc or valadoc
> (dunno nothing about them)
>
>
> How could the library authors specify in a unique/simple way the classes
> they /don't /want part of the API?
> This is where I thought 'protected classes' would be an interesting
> annotation for this.

Ok, I see what you mean now. However, I don't think it makes sense to
distinguish between classes in public header files and classes whose
symbols are exported. All classes that are in public header files should
be exported and all classes that are exported should be in public header
files. So we only need two kinds of top-level classes: public classes (in
public header files and symbols are exported) and internal classes (in
private header files and symbols are not exported). The currently
available 'private' classes don't make sense at all at the top-level, as
there is no way you could ever access them (except when it contains the
main method).

I don't think we should use 'protected' for internal classes, this
conflicts with the 'protected' used for specifying accessibility to
subtypes. 'internal' sounds fine, in my opinion, it's also in line with
C#.

Juerg