Le mar. 24 sept. 2024 à 13:52, Federico Ferri <federico.ferri...@gmail.com>
a écrit :
> Greetings,
>
> during last years of development with QML I always wondered how to solve
> certain software engineering problems.
>
> First, defining private properties: I have seen sometimes doing:
>
> Item {
> property int publicProp: 40 + state.privateProp
> QtObject {
> id: state
> property int privateProp: 2
> }
> }
>
> which seems a rather clever workaround, except for some reason it does not
> work with QtObject itself (error: Cannot assign to non-existent default
> property):
>
> QtObject {
> property int publicProp: 40 + state.privateProp
> QtObject {
> id: state
> property int privateProp: 2
> }
> }
>
> it is possible to do:
>
> QtObject {
> property int publicProp: 40 + _.privateProp
> property QtObject _: QtObject {
> property int privateProp: 2
> }
> }
>
> but it exposes the private QtObject so it kind of defeats its purpose.
>
I am just answering this first point.
Do you really care? What are you trying to prevent? Why?
Having an internal object is "clever" as you mentioned but doesn't prevent
anything and adds yet another object instantiation (and further
indirection).
The `state` object in the first Item example can still be accessed with
`item.resources[0]` by a motivated person.
Until private properties are implemented in QML, I am just using the Python
convention for "private" properties. If I want to have a "private" property
in a QML object, I prefix it with an underscore.
This documents the property as an internal one that shouldn't be messed
with.
External users accessing and modifying will do that at their own expense,
and no guarantee is made about the consequent behaviour.
In the end it boils down to how you want to access the property in your
internal code.
Do you prefer `root._foobar` or `root.internal.foobar`?
Cheers,
Pierre-Yves
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
