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

List:       kde-core-devel
Subject:    Re: 3.0 RELEASE: Heading RC1
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-01-18 19:36:03
[Download RAW message or body]

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:
> > Given that we have to care about binary compatibility starting with the 3.0 
> > release, I would like to suggest a review of the KDE 3.0 API for the next 
> > few days. I would like to ask you if possible to check those classes you did 
> > _not_ mainly write yourself first, because one usually finds more errors 
> > in others code as in your own. 
> 
> While going through kdecore I noticed a few things.
> 
> * KCharSets
>   
>   - The constructor is protected but the destructor is public. This
>     class is meant to be accessed through KGlobal::charsets(), hence
>     I would suggest to make the destructor protected (KGlobal is
>     already marked as friend class) .
> 
>   - I think the two fromEntity methods should be made static, as
>     well as toEntity
> 
> 
> * KDEStyle. Objections against removing it? (it's #QT_VERSION <
>   * 300'ed anyway)
> 
> * 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
> 
> * KGlobalSettings
> 
>   The honorGnome() setting seems unused to me. Neither a grep in
>   kdelibs nor in kdebase shows up any results. Ok to remove?

More things I've found:

- 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)

- KStringHandler: - the methods use lower-case naming, which is
                    inconsistent to the rest of kdelibs/Qt. 

                  - the matchFileName method, what do you think
                    about removing it at all? What advantages of
                    QRegExp does it provide?

- KSocks: The documentation to the die() method says that this
  method should not be called at all. Objections against making it
  private?

- KPRocess: This classes uses QStrList in the public api for the
  arguments passed to the process. What do you think about moving to
  QValueList<QCString> ? (especially as the args() method returns a
  QStrList pointer which is extremely ugly IMHO)

- KSock: This class has a bunch of //BCI: remove in libkdecore.so.4
  comments. Is it okay to remove those?

- any objections against removing the whole KRegExp class, now that
  QRegExp supports back references? (unlike QRegExp KRegExp is not
  unicode safe..)

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