On Wed, 28 Sep 2016 19:55:21 -0500, Brent Worden wrote:
On Wed, Sep 28, 2016 at 6:08 PM, Emmanuel Bourg <[email protected]>
wrote:
Le 28/09/2016 à 17:11, Gilles a écrit :
> This what you've done, but it doesn't say why.
The class is only used by RandomSource, moving it to the same
package
and marking it package private ensures that it can't be mistakenly
used
(even if it's marked as internal).
Emmanuel Bourg
If it is only used by RandomSource, would making ProviderBuilder a
private,
inner class provide better isolation and further prevent misuse?
Misuse cannot be prevented; if someone really wants to instantiate it,
he can. [And "misuse" is a strong word: what can one do with that
class?
Why would someone use it in a way that brings no benefit whatsoever, a
way that would only jeopardize the future of his application?]
The point of putting "non-API" inside an "internal" package is to
clarify the design as much as possible:
* Users, don't use what's in "internal"!
* Contributors, you may need to fiddle with what's in there!
Singling out a class on the basis that in that one case we can use
the package-private feature blurs the design for no significant
advantage.
The same issue of protecting access is posed for all classes in the
"internal" package.
We prevent usage of that one class but not of the others.
If someone wants to shoot himself in the foot, he can do so with
all the other guns.
Consequently, I'm still against that change.
Gilles
Brent
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
