So I'm looking at this Solidity pattern where you define a custom library called GoonLib with an add function for handling uint256 operations. Then you create a custom type NumberoGoono (basically a uint256 wrapper) and attach the library to it using the 'using' keyword.
The thing is, you initialize an internal state variable _number with a value of 1, then you call _number.add(5) to execute the library function. It's a clean way to extend type functionality without bloating your main contract logic.
But honestly—why would you structure it this way? I mean, the pattern works for complex operations where you want to keep things modular. If you're doing batch arithmetic or sophisticated math calculations, attaching libraries to custom types keeps your code organized. For simple additions though? Feels like overkill. Depends on what you're actually building.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
16 Likes
Reward
16
5
Repost
Share
Comment
0/400
NoStopLossNut
· 13h ago
This library function binding pattern seems a bit "modular for the sake of modularity"... Does simple addition really need to be done this way?
View OriginalReply0
WhaleInTraining
· 14h ago
This NumberoGoono is really disappointing. Why make simple addition so complicated?
View OriginalReply0
UncommonNPC
· 14h ago
ngl, this kind of using library trickery is really satisfying in large projects, but small contracts really don't need to go that far
View OriginalReply0
StakeHouseDirector
· 14h ago
ngl I've been tired of this mode for a long time, simple addition really doesn't need to be such a hassle.
View OriginalReply0
GasFeeCrier
· 14h ago
Bro, this naming is a bit funny, NumberoGoono... feels like the name of a meme coin. But the using library setup is indeed quite clean.
So I'm looking at this Solidity pattern where you define a custom library called GoonLib with an add function for handling uint256 operations. Then you create a custom type NumberoGoono (basically a uint256 wrapper) and attach the library to it using the 'using' keyword.
The thing is, you initialize an internal state variable _number with a value of 1, then you call _number.add(5) to execute the library function. It's a clean way to extend type functionality without bloating your main contract logic.
But honestly—why would you structure it this way? I mean, the pattern works for complex operations where you want to keep things modular. If you're doing batch arithmetic or sophisticated math calculations, attaching libraries to custom types keeps your code organized. For simple additions though? Feels like overkill. Depends on what you're actually building.