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

Add ValueDelegate macro #1000

Merged
merged 2 commits into from
Feb 28, 2023
Merged

Add ValueDelegate macro #1000

merged 2 commits into from
Feb 28, 2023

Conversation

ranfdev
Copy link
Member

@ranfdev ranfdev commented Feb 15, 2023

closes #983

It works pretty well I'd say.

Should I add support for generics?

@ranfdev ranfdev requested a review from pbor February 15, 2023 21:55
@ranfdev
Copy link
Member Author

ranfdev commented Feb 17, 2023

Added support to make the newtype nullable, implementing ToValueOptional.
I won't add support for generics, unless requested.
Done

I should probably add another example on the properties macro taking advantage of this.

@ranfdev ranfdev added enhancement New feature or request needs-backport PR needs backporting to the current stable branch labels Feb 17, 2023
@pbor
Copy link
Contributor

pbor commented Feb 18, 2023

The code itself looks good to me, though given that this is a new API etc, before merging I would prefer to get a thumbs-up from someone who had approval permission for more than a couple of days :)

In the mean time let me bring up some bikeshedding: which alternatives have we considered to the ValueDelegate name? I do not find it super clear... how about ValueRepresentation or ValueRepr ?

@pbor
Copy link
Contributor

pbor commented Feb 18, 2023

Also, if nullable is specified, should we accept/use TryFrom and set None in case of error?

@ranfdev
Copy link
Member Author

ranfdev commented Feb 18, 2023

naming

ValueRepresentation is a bit too long. ValueRepr would be ok, but in any case I think ValueDelegate is clearer. The macro doesn't provide a full representation. The representation is delegated to the chosen type. GLib can't distinguish MyInt(i32) and an i32. So MyInt(i32) doesn't have a full representation. That would require registering another glib type.

should we accept/use TryFrom and set None in case of error?

No, because that would silently ignore the error. We would need a specific Checker inside the ToValue trait to handle the conversion and provide a useful error. I agree this can be useful.

@ranfdev ranfdev mentioned this pull request Feb 19, 2023
pbor
pbor previously approved these changes Feb 19, 2023
Copy link
Contributor

@pbor pbor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned, this looks good to me, but let's wait for other reviews as well before adding new API

@ranfdev
Copy link
Member Author

ranfdev commented Feb 20, 2023

@sdroege we would like a thumbs up before merging a new API :)

sdroege
sdroege previously approved these changes Feb 26, 2023
@sdroege
Copy link
Member

sdroege commented Feb 26, 2023

Seems good to me, please merge after solving the conflicts :)

@sdroege
Copy link
Member

sdroege commented Feb 28, 2023

So let's get this in now? @pbor ?

@ranfdev
Copy link
Member Author

ranfdev commented Feb 28, 2023

I wanted to merge it, I just needed a review to do so

@sdroege
Copy link
Member

sdroege commented Feb 28, 2023

Ah, because mine was discarded because of the rebasing. I see

@ranfdev ranfdev merged commit 2b91ec4 into gtk-rs:master Feb 28, 2023
@pbor pbor added glib-macros backported PR was backported to the current stable branch and removed needs-backport PR needs backporting to the current stable branch labels Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backported PR was backported to the current stable branch enhancement New feature or request glib-macros
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE REQUEST] Newtype support for #[property]
3 participants