A collection of comments that have come via email:
- Haiwen Zhao pointed out that the Track interface defined in org.lcsim is slightly different than that defined in LCIO proper. Tony Johnson replied that this is deliberate: LCIO defines a simple data structure while org.lcsim layers a more powerful interface on top.
3 Comments
Jan Strube
I believe that a well designed library separates persistent and transient classes, as is the case in org.lcsim (to some degree).
That way, analysis code is to some degree isolated from changes to the underlying structures, as it should be. Changes in LCIO should facilitate and drive changes in org.lcsim and vice versa, but not require them.
Unknown User (kutschke)
Can you please elaborate a little and give a concrete example of something you think is a good idea and something you think is a bad idea?
Jan Strube
Good example: Using the org.lcsim Track interface for analysis and LCIO for persistence.
Bad example: Using LCIO for analysis. The classes are too low level.
Bad example 2: Streaming org.lcim classes for persistence. There is a lot of functionality that is unnecessary to persist.
It's a good thing that we can use the same org.lcsim tags with different versions of LCIO and vice versa.
The higher the level of org.lcsim classes that I use, the less analysis code I have to write.
The lower the level of the persistent classes, the better the performance and the easier the design.
This is of course an oversimplification to underline my point that a difference between org.lcsim Track and LCIO Track is not a reason to change either.