Stefan Andersson wrote: > > > > 2) Going from 'private' to 'protected' because of the need to > > > subclass in a particular proprietary application should never be a > > > problem. This strenghtens the API. > > > > This is not always the case. See > http://opensimulator.org/mantis/view.php?id=3072. Sometimes there are > good reasons > > for keeping methods private. > > I think that discussion has to be separated; I don't know the reason for > those members to be kept private (other than that the plugin 'wasn't > intended to be subclassed' which is fair enough) but I can say that > generally the only reason to hesitate over going from 'private' to > 'protected' is if code is written so that state integrity is pivotal for > method execution - something that usually points to the code being > brittle in the first place. (Compare with calling virtual members from > constructors for a similar concern) > > I am perfectly aware that this is touching on religion so I won't push > the issue further; suffice to say that "in most cases" we should not > have a problem with it.
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. 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). > > For the interested, I suggest you google for religious flame wars on the > proper use of "internal" and "sealed" as well. ;-) > > By the way, I take your +1's as meaning we're discussing this in order > to form an explicit concensus - 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. > > Best Regards, > /Stefan > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
