> I do agree with you. I think that the important thing here is that the patch 
> creator and applier both think carefully 
> about the situation when private members are being made protected.


Of course.

 
> One advantage of private members is that they tend to make debugging and 
> reasoning about code considerably easier. For 
> instance, if I know no other code can call a particular method because it is 
> private, then that means I don't need to 
> hunt down references or reason about possible interactions between different 
> callers. However, these arguments are 
> stronger, I think, when fields are public rather than protected (I have spent 
> too much time trying to unpick 
> interactions with Scene where callers were directly manipulating public 
> fields where this was not desirable or necessary).


You make a very good point; I actually was going to write that for example 
functions that are extracted to add semantic information normally should be 
kept private (and does not really need to be separately tested) since they are 
conceptually still a part of another context; then again, if any derived code 
would see fit to use those methods, I would have a hard time accepting a 'no'.

 

And regarding 'public', one of my pet decoupling strategies is just to turn 
stuff that is public to protected and see what breaks, then have a really hard 
think about why the 'breakee' needs public access. Another one is to 
encapsulate a public field in a getter-only property and see what breaks.

 

Those two excercises can be very enlightening.

> > If I have recieved no strong objections, 
> > I will add this to the code conventions by friday 20/2 2009.
> 
> Well, you know, I was just idly agreeing with you :) But it would be good to 
> have such things in the code conventions.


Yeah, I'm just jumping at the occasion. ;-D

 

Btw, I suggested a 'commit recipe' a while ago, I think I'll add that as well.

 

/Stefan

 
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Reply via email to