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

List:       kde-devel
Subject:    Re: KDE4todo #50
From:       David Faure <faure () kde ! org>
Date:       2006-05-03 13:03:11
Message-ID: 200605031503.11880.faure () kde ! org
[Download RAW message or body]

On Wednesday 03 May 2006 01:24, Will Entriken wrote:
> > > Were all of these pointers and hashes and private magic classes all
> > > used just to preserve binary compatibility while stuffing in more
> > > member variables? If so, you think they would have a standard way of
> > > doing that?
> > Well the dptr() magic yes. I don't know why the constructors of RMB were this way. (Didn't \
> > write those.)
> 
> > And as we don't want to eventually return to this magic, every (non-trivial) class should \
> > have a d-pointer. So you should add a member (or rather not remove) pointing to a private \
> > class. (Document that it is currently unused.)
> 
> How does this look:
> 
> --- kbookmarkmanager.h  (revision 536761)
> +++ kbookmarkmanager.h  (working copy)
> @@ -278,6 +278,13 @@
> 
> QString m_editorCaption;
> bool m_browserEditor;
> +
> +    /**
> +     * If you want to extend KBookmarkManager without breaking binary
> compatibility,
> +     * put additional members into this class. When you can break
> compatibility, move
> +     * members into KBookmarkManager and remove the implementation of
> this private class.
> +     */
> +    class KBookmarkManagerPrivate* extraMembers() const;
> };

There's a d pointer in each and every class in kdelibs, please use the same mechanism
as the other classes - i.e. simply a d pointer, not a method [which wouldn't work, where
would the instance be kept...].

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

 
> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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