Does it make sense to offer a property that wraps an external value?

[seanharmer]

In some cases such as material classes in Vulkan or OpenGL based applications, we may want to have some packed data that can be copied to a Uniform Buffer Object (UBO). Using Property members does not allow this as the signals are also interleaved in the memory layout of the containing class.

Would it make sense and be feasible to offer a RefProperty (name open to improvement) that acts just like a Property (signals and can participate in binding expressions) but which reads and writes data to a provided reference.

Consider:

class Material
{
public:
  Property<vec3> baseColor;
  Property<float> metal;
  Property<float> roughness;
  Property<float> ambientOcclusion;
};

This is not good to transform into a UBO that would like to layout data like:

struct UboMaterialData {
  vec3 baseColor;
  vec3 metalRoughAoFactors;
};

Would this alternative make sense and be feasible?

class Material
{
public:
  RefProperty<vec3> baseColor{ &d.baseColor };
  RefProperty<float> metal{ &d.metalRoughAoFactors.x };
  RefProperty<float> roughness{ &d.metalRoughAoFactors.y };
  RefProperty<float> ambientOcclusion{ &d.metalRoughAoFactors.z };

private:
  UboMaterialData d;
};

[LeonMatthesKDAB]

Hm, this seems slightly problematic in the sense that the Property now no longer owns the data it refers to, which means someone could change said data without the property emitting a changed signal.

Maybe it would instead be better to improve the support for properties with struct or class types?
That way one could just do:

class Material
{
  struct MaterialData {
    vec3 baseColor;
    float metal;
    float roughness;
    float ambientOcclusion; 
  };
public:
  Property<MaterialData> properties;
};

With some improvements to the property API this could then be accessed just with:

makeBoundProperty(material.properties->baseColor);

or something similar.

Would that fit your use-case, or do you really need individual properties for each value?