On Montag, 5. August 2013 17:20:16 CEST, Jan Kundrát wrote:
It might be better to separate this into two classes.
One that implements the addressbook and one that implements
the interface using an instance of that class.
One reason is that anyone creating new plugins will look at
the existing plugins and it would be better to clearly show
which parts are the plugin and which are the code dealing with
the actual data access behind the scenes.
But it would be good to get the opinion of the ABook code
creator/maintainer on this first.
This one is for Thomas. From my side, splitting them in any way
which makes sense is OK as long as it doesn't complicate the
code too much (and now I see that it probably explains what I
asked about in my review, I guess).
The comment about the existing plugins being used as a baseline
is a valid one.
Well, either AbookAddressbook and BE::Contacts share a common AbookBackend
class (with public funcions/members) or AbookAddressbook befriends BE::Contacts.
Publishing stuff because one user (which originally was the same class) needs
them is pretty wrong, yes =)
From a didactical POV, operating on a common semi-d-ptr is certainly the better
solution, so +1
Thomas
