Home » R3BRoot » Data Analysis » Data levels in R3Broot - suggestion
| Re: Data levels in R3Broot - suggestion [message #18969 is a reply to message #18968] |
Wed, 03 February 2016 11:14   |
Hector Alvarez Pol
Messages: 21
Registered: July 2015
Location: Univ. Santiago de Compost...
|
occasional visitor |
From: *usc.es
|
|
Hi,
yes, we should converge soon. And I agree that descriptive names are the best for everyone.
- I also agree with Builder as Ralf said. As pointed out by Dmytro, Finder is not suitable for all, but it could even be better to simply say that it could be Builder or any other similar word that suits perfectly to the task (as could be "Converter", "Filter", "Calibrator"???).
- Precal1, Precal2 were simply generics. I was trying to state that we can have several intermediate data levels. I agree with you that intermediate levels could be added for detectors provided the name is clear enough, and we should fix some basis (Mapped, Cal, Hit, ...). We could ask simply for agreement before selecting the name of additional intermediate states to ensure that the name is ok.
- The only point where we disagree (I think) is in the Item for data levels. In my opinion, a level like R3BNeuLandHit or R3BCalifaCrystalCal is clear enough, and I do not need the word Item to understand that is a data level. It is impossible to mistake them with "conversors" as they will have the Builder suffix, or parameters with the Par suffix. So, I do not understand Ralf's quote: "It describes that the class holds ONLY ONE Item, as opposed of all MAPPED or CAL level data", because all classes are abstraction of objects and are a single item in a sense. Then, one could instantiate many objects... Maybe I did not get the point properly.
Best regards,
Héctor
|
|
|
|
Current Time: Fri Apr 26 16:14:35 CEST 2024
Total time taken to generate the page: 0.01119 seconds
|
GSI Forum
Search
Help
Members
Login
Home
