Sacrificing operator= to avoid UB and hacks is probably fine (though I
expect some grumbling about the API). But would you suggest that
"real" (non-pimpled) QProperties and "fake" (pimpled) properties have a
different API?
And would you change the the property design to always go through the
setter when a binding becomes dirty?
Am 21.07.20 um 15:16 schrieb Volker Hilsheimer:
Taking a step back.
I wonder if we can avoid this problem if we require people to write a bit more
code. The idea to operate on the property directly looks nice at first sight, ie
auto oldValue = object->enabled;
object->enabled = newValue;
but that seems to be the only reason why we need the maybe-zero-sized members in
public classes, and the pointer-arithmetic to get to “this"; I’m not convinced
that it's worth it.
Realistically [1] we will have a lot of classes that would be a mix of old and new
properties. Especially with that in mind, we do need to make sure that we have API
consistency. For example, the property getters for boolean properties have always
been called isProperty; never just “property". The new system departs from
this. Making it cleverly generate an isProperty getter is just more magic.
Requiring the implementing getter/setter methods explicitly, just today, is
fine, I think. We might get something better later, but time is ticking and
this shouldn’t stop the show.
To set up bindings, one needs to do something like this with the current desitn
(I might miss some variants):
sink->otherProperty.setBinding(source->property);
sink->otherProperty = Qt::makePropertyBinding(source->property);
sink->otherProperty = Qt::makeBinding([&](){ return source->property; });
If instead we need to make a call on the source object, then it would remove
the entire “this” pointer problem. To make the call unique for each property,
we just have to declare a type for each property, which is easy.
sink->otherProperty = source->makeBinding<Source::propertyType>();
I’ve hacked a quick poc up at
https://codereview.qt-project.org/c/qt/qtbase/+/308308
This is obviously not taking a lot of use cases into account, so I might be
missing a lot, but the concept should be fairly extensible, for intance for
subscribe, setValue, value methods. The only downside I see is that
object->property = newValue;
is not possible with this, but having to write
object->setProperty(newValue);
like we do today can’t be a blocker for the entire concept of bindable and
lazily evaluted properties.
Volker
[1] There might be many classes that we can’t port entirely over to the new
property system, at least not without subtle changes to behavior that we can’t
accept. Qt’s properties are not designed to be orthogonal; changing them
frequently has side effects on other properties; getters sometimes apply some
additional logic for defaults and overrides; we have virtual setters, etc. This
has turned out to be quite complex over the last 10 days of trying, and the
resulting code has not always been a step into the direction of maintainability.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
--
--
Fabian Kosmale
Software Engineer
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosm...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
