Skip to content
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

Support slices & structs as arguments to maketx call #1635

Open
leohhhn opened this issue Feb 6, 2024 · 1 comment
Open

Support slices & structs as arguments to maketx call #1635

leohhhn opened this issue Feb 6, 2024 · 1 comment

Comments

@leohhhn
Copy link
Contributor

leohhhn commented Feb 6, 2024

Description

As the title says, maketx call should be able to do this. I know this might seems like a hassle to develop, so let's have at least 1-level deep structs and slices containing 1-level deep structs & primitives for the v1.

I would like to avoid using maketx run to achieve this functionality, since I see MsgCall used much more on the UI/UX side, where you can simply pack arguments, instead of parsing arguments on the UI side into Gno code and then packing it into MsgRun.

@thehowl
Copy link
Member

thehowl commented Feb 8, 2024

I want to make something clear: we're not adding support for compound types on this converter (slices, structs, arrays, ...). I've already partly expressed my thoughts on it, but essentially it is a heavy duplication of the parsing work that is already done when parsing an expression within the GnoVM. I'm heavily opposed to making it work for any non-primitive type.

Discussing this in last week's review meeting, this what was me and manfred convened: #1591 (comment)

Of course this is open for further proposals. I see though that this issue and #1600 have a lot in common in terms of what they're trying to achieve.

When we touched on this with Jae some time ago, I recall that he mentioned that using Call should be "extremely safe" and seemed to be resistant to the idea of changing it. In any case, if we want to go in the direction of supporting compound types in Call, then I'll fight tooth and nail to make this work by replacing the current call message (ie. -func Hello -args 1 -args 2) to -expr 'Hello(1, 2)', so we don't have two parsers attempting to achieve the same thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants