Open behaviary opened 4 years ago
Would it be worth making it possible to call a smart contract function using either snake_case
or camelCase
, regardless of how it was written? In which library would it make sense to implement such a lookup & conversion? Would this be part of nearprotocol/NEPs#3?
Would that be simpler than your proposed module system, @potatodepaulo?
It could be. I think that we should rely on a convention at the end of the day. My opinion would be that you can call a function as you would expect in the environment it's invoked. This would most likely be part of meta data, yes.
On Wed, Feb 26, 2020 at 11:15 AM, Chad Ostrowski < notifications@github.com > wrote:
Would it be worth making it possible to call a smart contract function using either snake_case or camelCase , regardless of how it was written? In which library would it make sense to implement such a lookup & conversion? Would this be part of nearprotocol/ NEPs#3 ( https://github.com/nearprotocol/NEPs/pull/3 ) ?
Would that be simpler than your proposed module system, @ potatodepaulo ( https://github.com/potatodepaulo ) ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( https://github.com/near/devx/issues/5?email_source=notifications&email_token=ABS6YAWPXHZ4EO4YB6WYDM3RE25WHA5CNFSM4K2P5R7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENBQE7A#issuecomment-591594108 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/ABS6YAQTYLMGNFDCAD7IEFDRE25WHANCNFSM4K2P5R7A ).
Where the contract is init, we should have a mapping.
With this, the frontend API can stay the same no matter what. Long term, this mapping will be part of smart contract meta data.
Second benefit is that this is a place where you could actually pull in other contracts. This is the place where you would compose apps. I’ll write an NEP.