Should on-chain packages have Gno addresses?

[leohhhn]

Description

Packages can have addresses (example). This means they can hold coins issued by the Banker. This introduces a bit of confusion - imagine the following scenario:

• We want to deploy realm A. in realm A, we utilize some functionality from package B by importing it.
• When trying to see/manipulate the coin balance of realm A, you do so via the Banker API - std.GetCoins(addr Address).
• This is where the confusion might occur:
  From a perspective of someone who is learning and has a classic understanding of how smart contracts/blockchains work, the deployment of the realm (& presumably package) is represented by its instance on-chain - which is identified by its path & unique address.
• Then, since package B is identified by an address (and a path, of course), and is imported into realm A, there are two instances in play - that of the realm, and that of the package. If we fetch coins of the realm, will we also fetch the coins of the package, since the package is imported into the realm?

To clear up this confusion, we should either:

1. Limit the issuing and sending of coins to & from packages, and provide consistent error messages in a regards to this - ie GetCoins(packageAddress) => error: cannot get coins from package - packages cannot be coin owners.
2. Disable address derivation for packages altogether - have packages be defined only by their path. If we choose to do this, we should also talk about how we plan to handle versioning of packages (if we do at all).

[moul]

Packages are "addressable" by their PkgAddr and have a derived std.Address.

There is an ongoing effort to make std.Address the type, and std.Addressable an interface that can be implemented for anything, including a Go object. Therefore, in practice, we may have valid std.Address for objects at some point.

See this link for more details.

I understand your concern about confusion. I would appreciate additional feedback from others who may also consider it an issue or have proposed solutions. Please remember that addresses will not only be limited to accounts with wallets. In the future, we can expect to have a wider range of things that require addresses.