Open sebastianst opened 3 years ago
I implemented it like this originally but @matthiasgeihs convinced me to add ETHAmount
.
This way it prevents ETH/WEI mix-ups and is easier to use than convenience functions.
Otherwise we would at least need to link these convenience functions
Yes, we discussed that and even though ethereum developers might be used to juggling with *big.Int, it's not nice.
I still think that it adds more confusion than it helps. Users of channels are usually Ethereum experts. They probably already have their solution how to handle eth/wei in their frontends and configurations. Mixing up eth/wei denominated number is more of a beginner's issue. Even somewhat experienced Ethereum devs know that amounts are always denominated in wei. Only frontend devs have to take care of these conversions. And because the conversion from/to eth/wei is a frontend issue, it is, in my opinion, misplaced in this package, which has more of a "backend" nature.
I would find it confusing as a new user of this package that I now have to create an intermediary type ETHAmount
just to input an amount that my application probably already holds as a *big.Int
.
IMO a package should focus on one thing, in this case, Perun ethereum payment channels. The API is simply cleaner if it accepts the default go-ethereum type for amounts, that is, *big.Int
.
I think it would be better to scrap the
ETHAmount
type and just use*big.Int
. go-ethereum users are accustomed to work with*big.Int
and it is just confusing that they need to create special amount types. Handling ethereum amountbig.Int
should not be the scope of this wrapper package.For conversions, users can use free functions like, e.g., from Erdstall's
eth
package ((Eth|Wei)to(Wei|Eth)(Int|Float)
).