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

List:       kde-devel
Subject:    Re: KDE4todo #50
From:       "Will Entriken" <kde.org () 2006 ! phor ! net>
Date:       2006-05-02 23:24:28
Message-ID: c0be00e90605021624k3fca01cam13369c8235623a76 () mail ! gmail ! com
[Download RAW message or body]

> > 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;
 };

 /**

This could work similarly with the other classes.

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


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