Property Naming Convention

SMTK 's property system allows developers to create their own custom Property data structures as well as instantiations of any Property data structures defined in the system. For example, you can create a long property called “foo” on a resource simply by calling the following:

resource->properties().get<long>()["foo"] = 2;

So I am about to add the ability to control in the UI whether a specific attribute name can be modified and am planning on implementing this capability by using an simple bool Property. The question is how to “reserve” this Property instance name so that it:

  • Doesn’t collide with another developer’s design
  • Try to indicate what it is used for

What I propose is to do the following:

Naming Convention

Make the Property instance name as clear as possible by including the plugin, module, or role that is using it. So in this example I might call it one of the following:

  • smtk::UI:attributeNameReadOnly
  • smtk::extensions::qt:attributeNameReadOnly

I tend to prefer the first version only because it might be used in either Web or Desktop UI’s.


In addition I would propose that there is a file that lists all of the Property Instance Names reserved by that plugin / module. It would contain the following:

  • Type
  • Property Name
  • What it is “applied” to?
  • What does it represents?

So in the smtk/extensions/qt directory there could be a file called reserved_properties.txt that would look like the following:

bool smtk::UI:attributeNameReadOnly
Applied to smtk::attributes.
If present, indicates that the attribute’s name should be modifiable in the UI.


@chart3388 @amuhsin @johnt @dcthomp @C_Wetterer-Nelson @Ryan_Krattiger @ben.boeckel @aron.helser

I like the idea of using the :: for name spacing, it seems consistent with the rest of the string naming conventions in SMTK.

It may be worth while to include something that makes it clear that the string is just a property to avoid any potential confusion that the property is anything more than just a property.

  • smtk::UI::property::attributeNameReadOnly

However, that may be overly verbose considering they will generally be used in a context that it is clear they are properties plus the documentation along with it.

I like the namespace idea, though I would make 2 changes:

  1. Use “ui” instead of “UI” since there are no letters preceding it that would require camel-case.
  2. Since attribute is also used as a namespace, I would use double-colons to separate that as well:


+1 on using all lowercase, at least by default.

Fyi I prefer to use . for the separator instead of :: (e.g., ace3p.analysis-mesh) so as to not imply a c++ namespace or class name. Also, I suppose, to avoid the shift key.

1 Like

Now that you mention it, a . would satisfy my complaint about making it clear that this is for a property and not something else. I amend my previous comment and +1 the use of . separators for namespacing :slight_smile:

In C++ but not in Python which uses dots for namespaces. :slight_smile: But I am fine with dots as separators.

Privacy Notice