[Development] Property bindings in Qt 6

Ville Voutilainen ville.voutilainen at gmail.com
Tue Oct 1 07:45:17 CEST 2019


On Mon, 30 Sep 2019 at 21:06, Matthew Woehlke <mwoehlke.floss at gmail.com> wrote:
>
> On 30/09/2019 12.38, Ville Voutilainen wrote:
> > On Mon, 30 Sep 2019 at 19:12, Matthew Woehlke wrote:
> >>>     QProperty<QString> fullname;
> >>>     fullname.setBinding([&]() { return surname() + " " + lastname(); });
> >>
> >> I suppose this is convenient, but it also means creating a new function
> >> object for *every instance of the type*. A more "traditional" approach
> >> would only have *one* member function (that is called with the implicit
> >> 'this' parameter).
> >>
> >> Have you at least considered doing something similar here, i.e. instead
> >> of using a capturing lambda, instead use a stateless function that takes
> >> the owning class as a parameter?
> >
> > Which owning class?
>
> The class which has a property (QProperty).

The current design doesn't rely on any particular owning object, nor
does it in any way require
that there's only one for a binding.

> > How does that avoid making it a template anyway?
> I don't understand how that relates?

I wasn't sure whether your concern was about having to generate a
template specialization
for every 'owning class' or something else, looks like your concern
was about storing the state
that the captures form, so ignore that.

> It seems to me I could refactor this to take a `T (*)(Owner*)`, or at
> least the std::function equivalent, which would allow at least the above
> example (and, I would expect, most uses) to use a stateless function. As
> illustrated by Simon, *all* uses *must* use a state-containing functor.
>
> (Note: I did not check if the "real" implementation actually does this
> already and the illustration in the OP was just for brevity.)
>
> IOW, the example would look like:
>
>
>   fullname.setBinding(
>     [](Foo const* self){
>       return self->surname() + " " + self->lastname();
>     });
>
> This *might* be able to not only story just a function pointer, but
> store it statically for all instances of the specific property, which is
> much closer to the storage requirements for a "traditional" getter. As
> illustrated, the design must store a lambda with state for every
> *instance* of the property.
>
> Convenience is nice, but as presented, it seems to come at a non-trivial
> storage cost.

In the original example, surname and lastname are not owned by any
Foo. They can be properties
in any scope, nested under something or not nested under anything.
They can be nested under
different things, so there is no one 'const Foo* self' that works in all cases.


More information about the Development mailing list