-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: export foo as Bar
syntax
#1075
Comments
Thanks for your proposal. Introducing changes to the language does take time, so bear with us as we navigate this. In the meantime, considering code generation might be fruitful. We haven't fully tapped into its capabilities, and it offers promising solutions. On a related note, enhancing our CLI to call methods directly could be beneficial. This way, we can make variables like Additionally, integrating a language-focused feature like `exec’ is an avenue we could explore. For a detailed view, you can refer to this link. Lastly, there's a proposition about harnessing |
I think this proposal addresses an issue we have with existing contracts. I'd be curious to explore first if there are any better ways to improve this without changing the language syntax. In any case, I've added it as a discussion for the team meeting. Thanks for your proposal, @n0izn0iz :) |
Problem
Currently, if we want to make a new realm that exposes a standard (for example a new grc20, grc721, or a DAO) we need to copy all public functions from the interfaces we want to support, this could be a lot of boilerplate, especially if you want your realm to support multiple interfaces
For example, for a grc20, that's this whole block:
Proposal
Support this syntax in realms global scope:
Where
Bar
is an interface andfoo
is an object implementingBar
This would make all
Bar
methods public realm methods usingfoo
as implementationFor example:
Would make all methods of
grc20.IGRC20
public realm functions usingfoo20
as implementation and thus this single line could entirely replace the boilerplate we saw previouslyMaybe we could also support
Where it would expose all public methods and members of
foo
Questions
In the
foo20
example, thegrc20.IGRC20
interface return errors but thefoo20
realm functions panics on those error, if we do addexport
, should we convert errors to panics?Alternatives
We could use the registry pattern like in #1072 and expose the common methods on the registry realm but this would break the authority patterns using
std.PrevRealm
since the registry would be the previous realmThe text was updated successfully, but these errors were encountered: