Static Status bits of Properties

[abdullah]

I am playing with Property status bits and I have found this status bits in Property.h:

Code: Select all

       // The following bits are corresponding to PropertyType set when the
        // property added. These types are meant to be static, and cannot be
        // changed in runtime. It is mirrored here to save the linear search
        // required in PropertyContainer::getPropertyType()
        //
        PropStaticBegin = 21,
        PropDynamic = 21, // indicating the property is dynamically added
        PropNoPersist = 22, // corresponding to Prop_NoPersist
        PropNoRecompute = 23, // corresponding to Prop_NoRecompute
        PropReadOnly = 24, // corresponding to Prop_ReadOnly
        PropTransient= 25, // corresponding to Prop_Transient
        PropHidden   = 26, // corresponding to Prop_Hidden
        PropOutput   = 27, // corresponding to Prop_Output
        PropStaticEnd = 28,

        User1 = 28, // user-defined status
        User2 = 29, // user-defined status
        User3 = 30, // user-defined status
        User4 = 31  // user-defined status
    };

I understand that the developer wanted this status bits to be static. My question is why?

BTW: setStatusValue masks many of them, but not all. For example, I can dynamically change PropNoPersist. In fact, dynamically changing this one may be useful for me. This is why I am interested in known why I should not.

[abdullah]

...

I would appreciate if you could let me know what is behind this type static properties.

I have a property that I would like to dynamically change from persistent to non-persistent. Currently I am doing it because you forgot to mask PropNoPersist in Property::setStatusValue. See here.

If there is indeed a strong reason to have the static, setStatusValue should be fixed to extend the ban.

I am interesting in:
1) the reason for having this Prop... status bits,
2) the reason why they shall be static
3) getting the dynamically settable persistence state. Here I value your input.

[realthunder]

I would appreciate if you could let me know what is behind this type static properties.

Those static property flags are mirrored from Prop_XXX bits when you add the static property using ADD_PROPERTY_TYPE() macros. They are static because those flags are stored as static data in property container. This is a design choice made before my involvement. I mirrored those static flags into the Property::StatusBits to save the trouble of looking up the property data inside the container, which is potentially expensive.

I have a property that I would like to dynamically change from persistent to non-persistent. Currently I am doing it because you forgot to mask PropNoPersist in Property::setStatusValue.

Yes, I forgot to do that. I did fix it in one of the pending PR. It is not critical as nobody is really using Prop_NoPersist. But yeah, it should be masked here.

1) the reason for having this Prop... status bits,

I can only guess here. Because they are for the static properties, which means the same type of object will have the exact same sets of properties, so to save some memory, they are stored as static variable.

2) the reason why they shall be static

I think the above reason is outdated, but it still has its use. I consider it as a way for the built-in object to enforce certain attributes of a property, which cannot be changed by user.

3) getting the dynamically settable persistence state. Here I value your input.

How about use the 'Transient' bit? I didn't add NoPersist status bit because I don't see its usage for dynamic properties, as they can be freely added or removed in the first place. And it is probably better to use dynamic property if you want to change its persistent status.

[abdullah]

And it is probably better to use dynamic property if you want to change its persistent status.

Thanks for your overall insight.

I have never used dynamic properties. I see an advantage to cases where some properties are optional or are only valid under certain "Modes". I do not see the drawbacks yet (that will come).

I am going to try to do an implementation for the Chamfer feature PR with dynamic properties. I have seen an example in ShapeBinder.