D pointers

[Stephan Kulow]

Am Samstag, 1. Oktober 2005 21:59 schrieb Cornelius Schumacher:
> On Saturday 01 October 2005 18:38, Stephan Kulow wrote:
> > Your classes? That are? I think it's fair to say I will revert your
> > account if you stay out of a discussion to come up with a policy and then
> > revert changes because you don't like the policy. This is not about
> > personal taste, this is about a consistent API.
>
> d-pointers and private data members hopefully are still not part of our
> API.
>
> This discussion reminds me of discussing tabs vs. spaces. We have no policy
> about that for a reason.
Yes and no. We have no policy there because it doesn't matter. If someone
drops out, the new maintainer can very easily run indent in his liking over 
the code. But he won't be able to move member variables around, so I think
it's very reasonable to define a default here - because you see yourself this 
topic is far from obvious and if we have a policy that gives new maintainers 
something to read, I think it's pretty import to have.

I don't see a reason to give new developers any input on what xemacs (a given 
though ;) settings they should choose for their own code. But I do see a 
reason to give them input on where to put their private functions/members - 
especially after this discussion.

And we have to accept one other thing: we have plenty of code in kdelibs that
has no real maintainer, but is maintained by a lot of people and I think the 
more people work in code, the more use have policies.

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

Greetings, Stephan