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

Handling of members of aggregate types #30

Open
zakalawe opened this issue Mar 31, 2022 · 2 comments
Open

Handling of members of aggregate types #30

zakalawe opened this issue Mar 31, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@zakalawe
Copy link

When T is an aggregate type, eg struct Rect { int x; int y; int width; int height; }

It would be great to be able to access members of Property, i.e that:

Property<Rect> r;
auto widthProp = makeBoundProperty(r.width);

This slightly overlaps with what @lemirep is asking about in #28, except in my case the aggregate does not contain Property<> members. The desired behaviour can be done using a function argument to makeBoundProperty : the question is whether some overload of operator-dot (and ->, presumably) could synthesise the access.

@zakalawe
Copy link
Author

There's an interesting case here that widthProp could in simple cases be write-able. However, this would need a different API, to track const- vs non-const bindings, I guess.

So you could do:

Property<Rect> r;
auto widthProp = makeBoundPropery(r.width);
widthProp = 99;

and this would trigger bindings on r

I can guess making this work for arbitrary deep nesting is impossible, but for the common case of types such as color, date or vec3 / mat4, it feels like it would be useful enough to support.

@LeonMatthesKDAB
Copy link
Contributor

There's an interesting case here that widthProp could in simple cases be write-able. However, this would need a different API, to track const- vs non-const bindings, I guess.

I'd say this is a separate issue, that also came up frequently, which is two-way bindings. (i.e. assign the "result" of a binding and if it's direct, write it into the source).

Otherwise adding support for . and -> operators is definitely interesting, but will need more research.

@LeonMatthesKDAB LeonMatthesKDAB added the enhancement New feature or request label Apr 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants