Make it possible to store components in UserData collections

[tmadlener]

BEGINRELEASENOTES

• Enable the possibility to store components in UserDataCollections.

ENDRELEASENOTES

This is a sort of compromise between being very strict and allowing only a few builtin types to be stored in UserData collections and opening them up for more or less arbitrary (POD) structs. It gives us a bit of control and we can pretty easily generate the necessary I/O code for things that are not just builtin types.

@paulgessinger this would be a prototype version of the functionality that we discussed briefly.

• documentation

[paulgessinger]

Any chance this could be exposed as a public compile-time boolean? I can use the detail namespace of course, but would be nice to use public API only.

[tmadlener]

Do you mean the isComponent, or the whole expression in the enable_if?

[paulgessinger]

Ideally the whole expression. The type tuple is already public so with my own isInTuple I can use it, but there's no good way to check if a type is a component from the outside.

[tmadlener]

Done. We also do the same in our GenericParameters so I don't see a reason to not do this here as well. Plus in this way we can keep the isComponent bit in detail and not expose that directly.

[tmadlener]

Closing this for now, as we don't have plans for really implementing this as it is more or less possible to do a similar thing with a normal datatype. In your case I suppose the major point was the interoperability with std::vector?

[paulgessinger]

I suppose the main difference is how to discover if a data type is valid for writing like this. If I add another mechanism to flag other types as being available in the edm, then indeed it should be possible to add them in the required way.

The other benefit of UserDataCollection is that it allows me to get mutable references to the underlying objects, which I need for my developments.

[tmadlener]

The other benefit of UserDataCollection is that it allows me to get mutable references to the underlying objects, which I need for my developments.

Really? That is probably a bug then, as it's at least not intended to be able to mutate objects after they have been read / obtained from a Frame.

[paulgessinger]

No the mutable references are just available for non-const references to UserDataCollection, I believe. And that's fine, my EDM infrastructure correctly wraps podio objects read from frames, and will not allow mutation even if this was technically possible in memory (which I don't think it is).

What I was referring to is the interface restriction of datatypes, which allow getting a const reference via getX and setting a property via setX. What I need (and am able to get via components) is a mutable-reference (from mutable podio collections only!) directly into the backing storage. UserDataCollection also allows this directly, as mentioned above.