{
};
```
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [June 19, 2019, 6:42pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/7 "2019-06-19T18:42:27Z")
I think since the goal of the property system is to allow _free form_ storage, we should not be restrictive by whitelisting what may be stored or not.
1. What abuses are you worried about?
2. I can imagine wanting some properties to avoid serialization. That functionality could/should be provided by `propmapbase`:
```auto
class propmapbase
{
public:
propmapbase(bool serializable = true);
bool serializable() const { return m_serializable; }
protected:
bool m_serializable;
};
```
3. We could expand the property system to include other things in the model system (Entity records, tessellation, etc.) if we wanted to. Would you consider that abuse? I think it would be nifty and could potentially eliminate a lot of code.
---
### Author:  [@Haocheng\_Liu](https://discourse.kitware.com/u/Haocheng_Liu)
#### Post date: [June 19, 2019, 6:56pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/8 "2019-06-19T18:56:44Z")
> [@dcthomp](#):
>
> I think since the goal of the property system is to allow _free form_ storage, we should not be restrictive by whitelisting what may be stored or not.
>
> 1. What abuses are you worried about?
I take it back. After a second thought, I think you are right as the free form storage opens a new world to SMTK. See my comments below.
Edit: Still I prefer something at compile time(So we have a control of what users can use and developers are free to expand it in their own session).
> [@dcthomp](#):
>
> We could expand the property system to include other things in the model system (Entity records, tessellation, etc.) if we wanted to. Would you consider that abuse? I think it would be nifty and could potentially eliminate a lot of code.
+1. For instance, now I store rgg materials as string properties - Using string "materials’’ I can fetch a list of material names and using each material name then can I fetch its representation as a string property. Alternatively, it will be nice to store materials as its own native type(Ex Material class) and it also applies to rgg pins, ducts, assemblies. It saves the cost of serialization/deserialization of strings. Instead of being limited by string property, I can now use Pin/Duct/Assembly property directly.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [June 19, 2019, 7:21pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/9 "2019-06-19T19:21:20Z")
> [@dcthomp](#):
>
> What abuses are you worried about?
Exactly this:
> [@dcthomp](#):
>
> We could expand the property system to include other things in the model system (Entity records, tessellation, etc.) if we wanted to.
I don’t think we should use this system to store tessellation. It would be better to have something that is enforced by the compiler, rather than convention, for a concept that is ubiquitous across resources (there’s a “magic string” smell here).
If we were to restrict ourselves to things that were serializable to (and, thus, stored as) a string, it would result in a concise API and prevent abuse of this storage mechanism (for example, the RGG session currently avoids all of model’s infrastructure using property strings; this works for RGG where there is no clear mapping to BREPs, but it is difficult to enforce as a pattern).
I think storing properties as strings informs consumers of their purpose: while you **could** store whatever you wanted by providing a serialization routine, you **should** use properties for storing properties, not things. Additionally, if serialization were implicit, then persistency would be automatic (a nice bonus).
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [June 19, 2019, 7:24pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/10 "2019-06-19T19:24:09Z")
> [@dcthomp](#):
>
> @tj.corona Are you thinking of something like this?
I was more thinking of templating the accessors to avoid `findString()`, `findDouble()`, `findInt()`. It’s a cool idea to template the entire storage of a property, but it could definitely be abused.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [June 19, 2019, 7:35pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/11 "2019-06-19T19:35:40Z")
> [@Haocheng\_Liu](#):
>
> Still I prefer something at compile time(So we have a control of what users can use and developers are free to expand it in their own session).
I really like the concept of a compile-time description of things that can be associated with a resource (hooray compile-time checks!), but I can see the utility of a runtime-defined property system as well. Also, as I mentioned above, I think a compile-time list of properties enforces a pattern that is going to be a bear to rein in once it is used to do things we didn’t originally intend.
---
### Author:  [@johnt](https://discourse.kitware.com/u/johnt)
#### Post date: [June 20, 2019, 2:32pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/12 "2019-06-20T14:32:54Z")
FWIW, I am not sure there is any _demand_ for free form storage.
- As a reference point, I’ll bet that Simmetrix’ GeomSim hasn’t provided persistent properties of any type in its nearly 20 years of existence, so we might be solving a problem that doesn’t exist in the market.
- I don’t think we should allow, for example, storing one resource as a property on another resource.
- I have a bigger use case for ephemeral properties, for example, assigning material numbers to model entities at the beginning of export operations. But there are alternatives that make this a low priority requirement.
Having said all that, I can live with free-form properties as long as we add some syntactic sugar so people like me can easily use string keys and perhaps our current types – int, double, string – plus maybe json.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [June 20, 2019, 2:40pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/13 "2019-06-20T14:40:48Z")
> [@johnt](#):
>
> I don’t think we should allow, for example, storing one resource as a property on another resource.
The horror! The horror!
> [@johnt](#):
>
> I have a bigger use case for ephemeral properties, for example, assigning material numbers to model entities at the beginning of export operations. But there are alternatives that make this a low priority requirement.
I think it would be pretty easy to get ephemeral properties for free if they can also be persistent. If we are going to write .sbt files describing filtering routines that filter on properties, you will likely want properties to become persistent!
---
### Author:  [@Bob\_Obara](https://discourse.kitware.com/u/Bob_Obara)
#### Post date: [June 20, 2019, 4:14pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/14 "2019-06-20T16:14:01Z")
I completely agree in in terms of not making this too general purpose. If you want to model complex data with constraints thats what the attribute resource was designed for. This should be a simple POD-like class that maybe uses a dictionary to store its contents. It should be persistent though we may want to be able to “tag” some information as non-persistent so it wouldn’t be saved.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [June 26, 2019, 2:02am UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/15 "2019-06-26T02:02:08Z")
I have a branch with an initial sketch of what the property class would look like here:
[https://gitlab.kitware.com/dcthomp/smtk/commits/resource-property](https://gitlab.kitware.com/dcthomp/smtk/commits/resource-property)
There are a few things that would be needed to start using it:
- Switch the existing json I/O to use it. Note that currently smtk::model properties are all lumped into a single map from UUIDs to all properties (of all types) which does not exactly mirror this structure in memory (but which is probably more efficient space-wise since long UUID strings are not repeated).
- Switch the smtk::model and smtk::mesh APIs to use this for double/int/string properties.
Neither is a huge amount of work.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [June 26, 2019, 5:22pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/16 "2019-06-26T17:22:21Z")
> [@dcthomp](#):
>
> I have a branch with an initial sketch of what the property class would look like here:
>
> [https://gitlab.kitware.com/dcthomp/smtk/commits/resource-property](https://gitlab.kitware.com/dcthomp/smtk/commits/resource-property)
This is an awesome start! I have a couple of nits (for example, I don’t see where/how a property index is used), but I think this is great.
---
### Author:  [@Haocheng\_Liu](https://discourse.kitware.com/u/Haocheng_Liu)
#### Post date: [June 27, 2019, 3:54pm UTC](https://discourse.kitware.com/t/modernizing-generalizing-setproperty-operation/276/17 "2019-06-27T15:54:46Z")
> [@dcthomp](#):
>
> I have a branch with an initial sketch of what the property class would look like here:
>
> [https://gitlab.kitware.com/dcthomp/smtk/commits/resource-property](https://gitlab.kitware.com/dcthomp/smtk/commits/resource-property)
The implementation looks really beautiful! Some tiny nits from me: raw pointer and using of `new`🙂 .