Hi, 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
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:33 MET