koffice

[Dmitry Kazakov]

On Tue, Sep 29, 2009 at 2:28 PM, Thomas Zander <zander at kde.org> wrote:

> On Tuesday 29. September 2009 13.15.54 Dmitry Kazakov wrote:
> > Argh! =(
> > You are beaking encapsulation! Isn't this a basic principle of
> > object-oriented programming?
> > There is an object (doc), and there is it's interface (undoLastCommand).
> > And no calls to private members! (undo stack is private, right?) Why do
> you
> > use private members?
>
> The code is;
>
> m_doc->undoStack()->undo();
>
> undoStack is a public method, not a private member. There is no breaking of
> encapsulation in this code.
>

There is. The object, returned by undoStack(), *is* private. And you grant
full access for it to the caller. This means, you grant "full access to a
private member". And there is no difference whether it is granted through
m_doc->m_undoStack or m_doc->undoStack().

What are the consequences of such an api:
1) Revealing of our internals. What if the implementer of a doc decided not
to use QUndoStack for storing undos?

2) [most severe] KoDocument can't do any lock-management! This is a
disaster. At the moment we have the same issue with KisImage::projection().
It is used from KisView thread without ANY locking. It causes very much
artifacts due to races. But in KisImage's case it's much more difficult to
do it another way.



-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090929/01882d4b/attachment.htm