<table><tr><td style="">mpyne added inline comments.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D24046">View Revision</a></tr></table><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D24046#inline-143879">View Inline</a><span style="color: #4b4d51; font-weight: bold;">broulik</span> wrote in <span style="color: #4b4d51; font-weight: bold;">personssortfilterproxymodel.h:53</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">"You can ... reimplement virtual functions defined in the primary base class hierarchy (that is, virtuals defined in the first non-virtual base class, or in that class's first non-virtual base class, and so forth) if it is safe that programs linked with the prior version of the library call the implementation in the base class rather than the derived one. This is tricky and might be dangerous. Think twice before doing it. Alternatively see below for a workaround."<br />
Now I'm confused :(</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">Approximately no one uses C++ virtual classes (which are a separate feature from virtual methods which we are used to).</p>

<p style="padding: 0; margin: 8px;">Basically, reimplementing a virtual function that's already defined in a base class can be binary compatible for already-compiled programs because it doesn't change the size or calling convention of the virtual table: there was already a slot in the virtual table to call the base class's implementation of a virtual function, and we replaced the pointer in the virtual table to instead call the newly-implemented virtual function in the derived class.</p>

<p style="padding: 0; margin: 8px;">The catch is that already-compiled code is not guaranteed to call the derived class implementation (due to inlining or other optimizations, for instance) so you cannot absolutely rely on your new implementation being called.</p>

<p style="padding: 0; margin: 8px;">If you have to think too hard about whether it's safe or not, it's best to assume it's not.</p>

<p style="padding: 0; margin: 8px;">In this case we're literally just calling the original implementation anyways, and <tt style="background: #ebebeb; font-size: 13px;">Q_INVOKABLE</tt> is just to register it to the meta-object system, so I think this should be fine. But if we want to use a separate method I'd label it as "KF6 TODO" or something similar so that we can go back and fix it up.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R307 KPeople</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D24046">https://phabricator.kde.org/D24046</a></div></div><br /><div><strong>To: </strong>nicolasfella, apol<br /><strong>Cc: </strong>mpyne, jbbgameich, broulik, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns<br /></div>