Re: [Vala] protected classes

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

On Wed, Apr 2, 2008 at 7:42 PM, Jürg Billeter <j bitron ch> wrote:
> On Wed, 2008-04-02 at 19:04 +0200, Ali Sabil wrote:
>  > On Wed, Apr 2, 2008 at 3:23 PM, Juerg Billeter <j bitron ch> wrote:
>
> > >  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 ?
>
>  How exactly do you use private top-level classes at the moment? Do you
>  have multiple top-level classes in one source file, some of them private
>  and you access the private class from the public class?
>
Yes that's exactly it.

>  Wouldn't private inner classes work fine, too, in that case?

Right, inner private classes should work fine for most cases, I just
don't really like them (I find it difficult to deal with deep nesting
code), but that's a matter of taste.

--
Ali