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

contract: change return type of public_key() to String #683

Closed
wants to merge 2 commits into from

Conversation

ppca
Copy link
Contributor

@ppca ppca commented Jul 15, 2024

Using String instead of AffinePoint for better readability

@ppca ppca requested a review from volovyks July 15, 2024 20:36
@ppca ppca linked an issue Jul 15, 2024 that may be closed by this pull request
@ppca ppca requested review from ChaoticTempest and ailisp July 15, 2024 20:36
@ppca ppca changed the title contract: change return type of public_key() to <Secp256k1 as CurveArithmetic>::AffinePoint contract: change return type of public_key() to String Jul 15, 2024
@ppca
Copy link
Contributor Author

ppca commented Jul 15, 2024

@volovyks With String return type, the public_key() fn call returns
"secp256k1:291ASHiiHRMCj1k6iVSvsFeYUBEvRNsk9TTWKfVw9wgkdGhWvcPHGMzPd2BZy2UVcobm9DfdKSM9GTeWAzNSjsWp"' in a local test, where if we return AffinePoint, the call will return something like ODxxxx, much less readable.
The user of the contract can choose to convert the String to whatever they'd like to use in their code

@ChaoticTempest
Copy link
Member

we should make our own custom type here instead of using String which can be very arbitrary what type it is. That way, we can support similar forms of parsing in our testing

@ppca
Copy link
Contributor Author

ppca commented Jul 15, 2024

we should make our own custom type here instead of using String which can be very arbitrary what type it is. That way, we can support similar forms of parsing in our testing

@ChaoticTempest This PR was addressing #665, which I think aims at returning a universal type instead of our custom type so users find it easier as @volovyks told me.
I'm ok either ways tho.

@ChaoticTempest
Copy link
Member

so our own custom type is actually the universal type, because we control what the semantics of it are. We need parsing logic at the end of the day anyways, so attaching it to our own custom type would be ideal because we can reuse it for testing and other users would be able to import it as well on Rust side of things

@ppca ppca closed this Jul 17, 2024
@ppca ppca deleted the xiangyi/pk_format branch July 18, 2024 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

return root and user pk as a point or string, not near_sdk::PK
2 participants