python/templates: add references between Objects and Collection types

[veprbl]

BEGINRELEASENOTES

• Introduce member typedefs to the user facing classes.
  • Object's collection type can now be referenced as Object::collection_type. Conversely, the object type is reachable as ObjectCollection::value_type. The mutable objects can be reached via Object::mutable_type.

ENDRELEASENOTES

This should allow to remove some codegen hack from EICrecon https://github.com/eic/EICrecon/blob/1f6727948696b70fc29b1fe582f23f2e37c476b2/src/services/io/podio/make_datamodel_glue.py#L76-L84

cc @wdconinc @nathanwbrei

[tmadlener]

Thanks for this proposal. I think this is very useful and also necessary (e.g. for #257). So my main concern for this PR here is to make sure that we do this comprehensively and consistently (also taking into account other c++ conventions).

Overall podio itself does not (yet) have a convention (or at least not one that is followed consistently) for member types. Since some of the exiting member types try to mimic the ones from std::vector for the collections, I think we should try to just continue there and try to follow the same convention of using <xyz>_type to define member types.

Then one question is which member types do the different (user level) classes need?

Finally one that mainly concerns Jana2 and how it is used there; Are there any concerns wrt breaking things when we introduce this?

[veprbl]

Thanks for this proposal. I think this is very useful and also necessary (e.g. for #257). So my main concern for this PR here is to make sure that we do this comprehensively and consistently (also taking into account other c++ conventions).

Overall podio itself does not (yet) have a convention (or at least not one that is followed consistently) for member types. Since some of the exiting member types try to mimic the ones from std::vector for the collections, I think we should try to just continue there and try to follow the same convention of using <xyz>_type to define member types.

Good suggestion.

Then one question is which member types do the different (user level) classes need?

The only type reference that we were truly missing was from object to collection, because no object method or member would provide that. I don't see what else we could add, the Obj, Data and CollectionData are not part of the public interface.

Finally one that mainly concerns Jana2 and how it is used there; Are there any concerns wrt breaking things when we introduce this?

Since this only adds fields, this should be backwards-compatible with any codebase.

[tmadlener]

Thanks for address the comments. Could you rebase this onto the latest master/merge that in to pick up the updated CI configuration, please?