4

Isn't it redundant to have a function that returns a simple public variable like this?

6

It's not necessarily so simple.

Suppose the token decayed over time. (I.e. demurrage) A reasonable contract design would have the actual balances lazily evaluated, by only subtracting the decayed tokens once the contract is accessed. The default getter would not be able to do this, and would return an inaccurate value.

There's plenty of other systems with similar complexity requirements, or even ones without a single number to represent the balance. In these cases, it's better that the interface makes no requirement as to how the balances are stored.

| improve this answer | |
  • I'm not sure I understand. Your saying some contracts should update the balance, when balanceOf() is called? Otherwise the getter would be up to date with the state of the variable right? – ethereal Jan 28 '17 at 16:57
  • Making it public does more than one thing and it's often undesirable to do all of those things. Example suggests one scenario among many; if there's a formula that's supposed to alter a value over time, that decay won't be calculated in a fluid way because the contract isn't running all the time. A lazy getter would be able to do math. "public" also means child contracts might be able to overwrite an important value by accident. Might be better to make it private and provide the getter yourself. Another case among many. – Rob Hitchens Jan 28 '17 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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