2

Why OpenZepplin always use private visibility with getter functions for its state variables? I can't find a reason why they are not using public, is there any potential security or gas cost difference when using private instead of public? mapping (address => uint256) private _balances;

mapping (address => mapping (address => uint256)) private _allowances;

uint256 private _totalSupply;

/**
 * @dev See {IERC20-totalSupply}.
 */
function totalSupply() public view returns (uint256) {
    return _totalSupply;
}

/**
 * @dev See {IERC20-balanceOf}.
 */
function balanceOf(address account) public view returns (uint256) {
    return _balances[account];
}

This pattern is repeated in all their contracts: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts

Improve this question

1 Answer 1

Reset to default
2

See issue #1174 in their openzeppelin-contracts repo.

"Solidity adds public getters to public state variables. This is kind of magical and dark, and could lead to mistakes.

We should be more explicit on everything we do, to make the code clearer and easier to review. So let's get rid of the automatic getters making all the public state variables private."

Improve this answer
7
  • 1
    I believe that this answer is incomplete, since one could easy argue (in response to this answer): "well, why didn't they use internal instead of private then? The answer to that one, I believe, is that they wanted to explicitly state that these variables should not be "messed with" (i.e., altered) by anyone who chooses to inherit the corresponding contract.
    – goodvibration
    Commented Sep 22, 2019 at 12:25
  • And BTW, this change in OZ code (starting from v2.0.0 if I remember correctly), has actually caused an issue with extending Ownable to Claimable. They have removed Claimable at that point, and since owner has become private, it could no longer be altered by anyone who wished to implement his/her own version of Claimable.
    – goodvibration
    Commented Sep 22, 2019 at 12:25
  • 1
    Yep, fair points. I've answered the question with the publicly available information, that being the initial comment on the issue from the OZ dev. Without asking them directly - and perhaps someone close to the project can chime in and confirm either way - any further reasoning would be conjecture. What you're saying makes complete sense though :-)
    – Richard Horrocks
    Commented Sep 22, 2019 at 12:36
  • @goodvibration Does it mean that public variables can potentially undergo security issues especially if someone choses to inherit the contract ? I don't get it, do a contract B that inherits from the contract A have the possibility to alter data of contract A and in particular its public variables ?
    – Kevin Wad
    Commented Sep 24, 2019 at 14:42
  • @KevinWad: Yes, for both public and internal variables of the parent contract. I wouldn't call it a security issue though. It's not like you can deploy B and then change variables of some other instance of A. You can only change your own variables (i.e., when you implement your B contract, you can change the variables declare at the A level, but those variables will be part of your B contract, not any other B contract out there).
    – goodvibration
    Commented Sep 24, 2019 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.