lars at trolltech.com
Mon Oct 3 07:19:05 BST 2005
On Sunday 02 October 2005 18:57, Cornelius Schumacher wrote:
> On Sunday 02 October 2005 09:35, Stephan Kulow wrote:
> > That having said, I for sure don't want to see a script output somewhere
> > somewhen checking. But I will review new kdelibs code for over-using of
> > inline functions (as we did in the past with d pointers).
> Ok, if the policy is "Avoid inline functions", than that's ok, because it
> really makes sense because it makes the code more extensible.
> But if the policy is "Move all private members to private classes" I would
> object, because this thread shows that there are no clear benefits and it
> is more a question of personal coding style.
The benefit is the greater refactoring possibilities you have. I can only say
that from past 5 years of coding in Qt I have missed this possibility quite a
few times just because a member happened to be in the class and not the d
People often don't get details right at the first try, and suddenly you find
you that you don't need a member anymore or you would like to reorganize the
member variables. All of that can only be done if you don't have the members
in the public classes.
When putting the members into the d pointer you don't have to be as careful
with your first implementation as if you put them into the public class. In
the d-pointer you can do everything you like; adding variables, removing
them, changing their type, reordering them, you name it. In the public class
you can do more or less nothing (there are some ugly hacks you could do in
some cases, but these tend to be really ugly and not give a clean
So if you think about long term maintainability of code it is clearly
preferable to have all members in the d-pointer.
More information about the kde-core-devel