as one of my homeworks problem after the ROOT workshop at Fermilab
I "rootified" the Vector package of CLHEP. But I have doubts
whether it is useful to release them to public use.
At the workshop it was agreed to "rootify" CLHEP. But it was
not too clear what the main purpose of these "rootification"
should be:
- Is it to incorporate functionality in ROOT which is not yet there?
- Or to use the codes written with CLHEP classes in ROOT without
changes?
- Or is it to use ROOT I/O for CLHEP objects?
What is the main objective: Ease of use for ROOT users or for
CLHEP users?
To use CLHEP functionality in ROOT one has at least the following
options:
1. Include some of the functionality of CLHEP in ROOT, i.e. take
ideas, algorithms etc from CLHEP to enhance ROOT.
2. Rootify CLHEP or parts of CLHEP
Minimal changes:
- generate LinkDef.h (to use CLHEP as is)
- insert ClassDef/ClassImp and inherit from TObject or TNamed
(to use ROOT I/O)
Medium changes:
- change types eg: HEPDouble -> Double_t ...
- change class names eg: HepLorentzVector -> TLorentzVector
- change math functions eg min/max/sqrt .. to TMath::Min/Max/Sqrt
(to get rid of CLHEPs TemplateFunctions.h)
Maximal changes:
- move to ROOT naming conventions
eg for member functions: setX() -> SetX(), x() -> GetX(), ...
- Change the comments to the ROOT documentation standards
eg move or copy the member function description from the
header file to the source file.
3. Wrapper / Adapter / Mixing classes in ROOT which delegates the
work to CLHEP
For option 1 it is important to know which packages are needed in ROOT,
which functionality is missing. Which of the packages:
Combination, Geometry, Matrix, Random, Units and Vector
(see the CLHEP homepage: http://wwwinfo.cern.ch/asd/lhc++/clhep/ )
are needed in ROOT. It would be a one-time
effort. I think it would be difficult to reimport changes
of the CLHEP after that first step.
With options 2 and 3 one has to decide whether it is useful to include
the full (fat!) interface of CLHEP or whether it should be minimized:
e.g. the new HEPLorentzVector class has three different access methods
to its components Fortran-like v(0) C-like v[0] and v.x() (there are a
lot of similar examples in the random classes).
Option 3 seems to me the promissing way.
- There could be a version problem but if it is possible to include
in CLHEP a version number which could be inquired at runtime it
could be implemented in a save way.
- It would be an example of one of the main objectives of object
orientation: using and extending existing programs without
modifiying them.
- The responsibilities and the credits of the ROOT and the CLHEP team
would be clearly exposed.
- It would be clear to users where to look for the documentation.
- The most important point: the maintance of such a scheme could
easily be semi-automated.
The ROOT team has agreed to incorporate a "rootified" version of
the Vector package into ROOT. However I am not convinced that a
simple "rootification" is justified. I see the following two
problems:
1. A set of classes along the lines of option 2 with medium changes
is ready. It would be easy to move it to the full ROOT naming
scheme, but than it would be more difficult to use existing code
(if one changes only types - a set of typedefs is all needed,
but if one changes memberfunction names ...).
2. Is it useful to put the full (for historical reasons) fat
interface into ROOT. A leaner version would be much better for
the normal ROOT user.
In short: my feeling is that the current version is halfway between
option 1 and 3 and therefore not too usefull for an experienced CLHEP
user (he has to change his code), but to difficult to overloaded
for somebody who will just use a LorentzVector class in ROOT.
Peter Malzacher
FNAL and GSI
email: P.Malzacher@gsi.de