<br><br><div class="gmail_quote">On Tue, Sep 29, 2009 at 2:28 PM, Thomas Zander <span dir="ltr"><<a href="mailto:zander@kde.org">zander@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tuesday 29. September 2009 13.15.54 Dmitry Kazakov wrote:<br>
> Argh! =(<br>
> You are beaking encapsulation! Isn't this a basic principle of<br>
> object-oriented programming?<br>
> There is an object (doc), and there is it's interface (undoLastCommand).<br>
> And no calls to private members! (undo stack is private, right?) Why do you<br>
> use private members?<br>
<br>
</div>The code is;<br>
<br>
m_doc->undoStack()->undo();<br>
<br>
undoStack is a public method, not a private member. There is no breaking of<br>
encapsulation in this code.<br></blockquote><div><br>There is. The object, returned by undoStack(), <i>is</i> 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().<br>
<br>What are the consequences of such an api:<br>1) Revealing of our internals. What if the implementer of a doc decided not to use QUndoStack for storing undos?<br><br>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.<br>
</div></div><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>