Some quick feedback on the 6.8 implementation of QT/Protobuf
-
In the latest iteration, classes generated from .proto files has made sub-classes immutable in C++.
I think this is a disastrous decision. Protobuf "messages" can be quite complex with many levels of Message's containing other messages as sub-members.
The native C++ protobuf implementation (from Google?) has "mutable_" methods, allowing direct mutable access to any member objects. In order to build a complex message, the message may pass trough several functions, or if statements, that add some state to various sub-properties before it's submitted. In it's current state, this will be very messy and inefficient, especially if each "substation" has to pull out any objects it want to modify, copy the data to new objects, modify the state, and then re-assemble the message with the updated state.
It seems like QT Protobuf is targeted mainly for QML. That is fine, but please remember that applications that is more than a few fancy screens will require a layer in C++ to handle the business logic. Until now QT/gRPC/Protobuf was significantly simpler to work with than the standard C++ code generated by protoc. That just changed dramatically over night.
Please either make a mutable version of "Message.property()", or add "Message.mutableProperty()".
-
In the latest iteration, classes generated from .proto files has made sub-classes immutable in C++.
I think this is a disastrous decision. Protobuf "messages" can be quite complex with many levels of Message's containing other messages as sub-members.
The native C++ protobuf implementation (from Google?) has "mutable_" methods, allowing direct mutable access to any member objects. In order to build a complex message, the message may pass trough several functions, or if statements, that add some state to various sub-properties before it's submitted. In it's current state, this will be very messy and inefficient, especially if each "substation" has to pull out any objects it want to modify, copy the data to new objects, modify the state, and then re-assemble the message with the updated state.
It seems like QT Protobuf is targeted mainly for QML. That is fine, but please remember that applications that is more than a few fancy screens will require a layer in C++ to handle the business logic. Until now QT/gRPC/Protobuf was significantly simpler to work with than the standard C++ code generated by protoc. That just changed dramatically over night.
Please either make a mutable version of "Message.property()", or add "Message.mutableProperty()".
@jarle said in Some quick feedback on the 6.8 implementation of QT/Protobuf:
It seems like QT Protobuf is targeted mainly for QML
It's also for serialization purposes in C++
See:Please either make a mutable version of "Message.property()", or add "Message.mutableProperty()".
For these kind of requests and suggestions for improvement better create a bugreport or contact Qt directly.
-
Hi @jarle,
First of all, thanks for using and giving feedback to Qt Protobuf/GRPC. The removal of mutable getters was the hard decision, but the removed implementation had an issue related to the moc, that we didn't manage to fix in time, unfortunately.
We will restore the functionality on further releases, not sure if 6.9 is the one, so don't give any promises here by now.
-
Here are two bugs for the context:
https://bugreports.qt.io/browse/QTBUG-119912
https://bugreports.qt.io/browse/QTBUG-119913And the change that removed them:
https://codereview.qt-project.org/c/qt/qtgrpc/+/585992P.S. The fact you complain about the removal, forces us to reconsider our decision.
