> > 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. 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. Best Regards, /Stefan
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
