[
https://issues.apache.org/jira/browse/JSEC-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665854#action_12665854
]
Les Hazlewood commented on JSEC-8:
----------------------------------
My personal opinion is that the issue should be resolved based on the
particular wording for this issue: "We are standardizing on protected from now
on".
IMO, we achieve any necessary extensibility for subclasses via the subclass's
use of the parent getBlah() accessor method, not necessarily by accessing the
parent class attribute directly.
I personally would like to use the getters where necessary and maintain
encapsulation at all costs. The more you open up, the more you can't 'take
back' once released into the wild. The majority of our classes shouldn't be
subclassed anyway, and for the few that should, I've kept some existing
attributes as 'protected'.
My primary driver in this issue is the 1.0 release. Once we're 1.0, we can
forget about changing things as often as we have during 0.x, so keeping things
as private as possible limits the changes that people might experience if they
were not as encapsulated.
Can we resolve the issue based on this and open a separate issue for specific
classes where you might like to see this enabled?
> Change instance variables from private to protected
> ---------------------------------------------------
>
> Key: JSEC-8
> URL: https://issues.apache.org/jira/browse/JSEC-8
> Project: JSecurity
> Issue Type: Improvement
> Components: Specification API
> Reporter: Alan Cabrera
> Assignee: Les Hazlewood
> Fix For: 1.0
>
>
> Currently most instance variables are private, which limits options when the
> classes are extended. We are standardizing on protected from now on, but the
> existing classes should be updated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
