
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

font-size: 10pt;

font-family:Verdana

}

</style>

</head>

<body class='hmmessage'>

 <BR>

> > 2) Going from 'private' to 'protected' because of the need to <BR>> > subclass in a particular proprietary application should never be a <BR>> > problem. This strenghtens the API.<BR>> <BR>> This is not always the case. See http://opensimulator.org/mantis/view.php?id=3072. Sometimes there are good reasons <BR>> for keeping methods private.<BR><BR>

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

 <BR>

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

 <BR>

For the interested, I suggest you google for religious flame wars on the proper use of "internal" and "sealed" as well. ;-)<BR>

 <BR>

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

 <BR>

Best Regards,<BR>

/Stefan<BR>

 <BR></body>

</html>