[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: 3.0 RELEASE: Heading RC1
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2002-01-21 11:46:03
[Download RAW message or body]

On Fri 18. January 2002 20:36, Simon Hausmann wrote:
> On Fri, Jan 18, 2002 at 06:56:34PM +0100, Simon Hausmann wrote:
> > On Thu, Jan 17, 2002 at 02:37:34PM +0100, Dirk Mueller wrote:
[snip]
> >
> > * KExtendedSocket:
> >   That class has a bunch of protected member variables. I would
> >   suggest to make those private and provide them protected only
> >   #ifndef KDE_NO_COMPAT

 I don't think that's a good idea (the KDE_NO_COMPAT part). I'd suggest 
making the members private, probably with KDE_NO_COMPAT inline access 
functions for those, if needed. Classes built with and without KDE_NO_COMPAT 
should be binary compatible, and having different access rights for data 
members might cause problems. C++ doesn't say data members in classes/structs 
have to be ordered like they're written in the class definition, the compiler 
has to keep only members in same access blocks of the class in the given 
order. Erm ... I hope you know what I mean.

> >
[snip]
>
> - What is your opinion on making KXMessage's protected members
>   private ? (all methods are @internal and protected member variables
>   in libraries help to make future expansions painful)

 Oops. Old bad habbit of mine. Will fix it. This is class is not meant to be 
used as a base class anyway.

[snip]

-- 
 Lubos Lunak
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli

[prev in list] [next in list] [prev in thread] [next in thread]