Link collections do not have a typeName member like other collections

[jmcarcell]

And therefore it is impossible to use coll::typeName as with the rest of the collections (see https://github.com/AIDASoft/podio/blob/master/python/templates/Collection.h.jinja2#L65). This was uncovered in key4hep/k4FWCore#276 (and fixed in key4hep/k4FWCore#277).

There exists a general function to obtain the type name for a Link collection: https://github.com/AIDASoft/podio/blob/master/include/podio/detail/LinkFwd.h#L21 but implementing this as constexpr to add it generally to all collections seems to be non-trivial. At the very least, constexpr string concatenation would have to be implemented, and I'm not sure if this is going to work in C++20.

Another option is to implement this in the template, making the actual collection type have this attribute by inheriting from podio::LinkCollection<From, To> and being slightly different from podio::LinkCollection<From, To>. This would be very easy to do in https://github.com/AIDASoft/podio/blob/master/python/templates/LinkCollection.h.jinja2#L14 because all the information is known at this time. I have a working implementation with this method.

And the last option is simply not to add this since there are not a lot of use cases.

[m-fila]

Another option is to implement this in the template, making the actual collection type have this attribute by inheriting from podio::LinkCollection<From, To> and being slightly different from podio::LinkCollection<From, To>. This would be very easy to do in https://github.com/AIDASoft/podio/blob/master/python/templates/LinkCollection.h.jinja2#L14 because all the information is known at this time. I have a working implementation with this method.

Wouldn't that solution have a significant disadvantage of forcing all the link declarations back to the yaml file which I think was the motivation to introduce the templated links?