Re: [Vala] protected classes

["Ali Sabil" <ali sabil gmail com>]

On Wed, Apr 2, 2008 at 3:23 PM, Juerg Billeter <j bitron ch> wrote:
> 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#.

I am not sure, but I currently find the private classes very useful,
and I use them quite often,
what about having public, private and package visibility for the classes ?

the public and private will be exactly the same as they are today, and
concerning the package
classes, those ones will land the the -priv.h header.

--
Ali