D pointers

[Lars Knoll]

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 
pointer. 

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 
implementation).

So if you think about long term maintainability of code it is clearly 
preferable to have all members in the d-pointer.

Lars