Only if using
VisibleXXX, this is more equivalent to a getter-only (or make the member variable a const pointer, which is often problematic for initialization).
But yes, there is no reason to allow blueprints to access a subobject and not allow C++ some form of access as well. I never disputed that.
And in the same vein, a lot of member functions should become UFUNCTION and be virtual and public/protected.
While I didn’t think of it in quite those terms, I don’t think it was different in essence.
Why does changing a property during development as opposed to runtime matter? It’s the effects of the changes that actually matter, and those effects do show at runtime too. The changes themselves are only important in so far as they are the source of those effects.
And even then, changes in one property in the editor (e.g. velocity) can also change other properties at runtime (e.g. location).
I give you that blueprints have more leeway in what they can change, and thus the effects those changes can have. But that doesn’t mean the editor has no opportunities. And in that light, I don’t think the editor is special compared to blueprints. It’s more limited (and harder to avoid because of basic properties such as the mesh and transforms) but I see it more as a matter of degree rather than specialty.
The “principle of least privileges” still means that one should avoid allowing blueprint access while still allowing the editor (since the former is not always required while the latter often is for practical purposes), but I don’t think one should have too much qualm allowing blueprints if they feel the need.