Made private methods internal to allow for overriding

[MickdeGraaf]

Makes private functions in ERC777 internal instead of private.

Making these methods internal allows for overriding and adding of functionality in tokens developers create.

Fixes #2047

Example usecase:

In DDAI interest needs to be claimed on every transfer.
Overriding every functoin like transfer, transferfrom, send and so on would add unnecessary complexity to the code. Thats why I override the _move function.

To prevent people from making unnecessary forks of this repo(like I did) I think its wise to make all functions internal instead of private.

[stale]

Hi all!
This Pull Request has not had any recent activity, is it still relevant? If so, what is blocking it? Is there anything we can do to help move it forward?
Thanks!

[frangio]

Hi @MickdeGraaf. Really sorry it took so long to reply to this.

Overriding every functoin like transfer, transferfrom, send and so on would add unnecessary complexity to the code. Thats why I override the _move function.

@nventuro and I have discussed this and we don't think it would be right for _move to be internal. We definitely want to support extensibility and your use case in particular, and although we agree that it would be nicer to override a single function, we feel more strongly about providing an internal API that respects the important properties of the contract. In the case of ERC777, the specification requires that all sends and transfers trigger function calls on the sender and the receiver, and exposing _move internally would allow to bypass this protocol, accidentally or not. If we were to expose something internally with the purpose of enhancing extensibility it would have to be something else that preserves this protocol.

[frangio]

Hi @MickdeGraaf, are you interested in continuing this PR or should we pick it up?

[nventuro]

Thank you for pushing for this @MickdeGraaf and @asselstine!

In v3.0 of OpenZeppelin Contracts, which will feature support for Solidity v0.6.x, we're planning on adding hooks on events such as token transfers and approvals. That should provide an easier extension mechanism than the current overriding of the internal functions, which can be dangerous. You can take a look at current progress and discussions in #2063.

Thanks again!

[MickdeGraaf]

Sorry missed the conversation. Thanks for merging!

The hooks sound very interesting!