On Mon, 20 Nov 2000, Christian Holm Christensen wrote: > Damn. I guess that's the price you've gotta pay for taking a short > vacation. > > I DO NOT LIKE THE IDEA OF BrValueObject!!!!! Hi Christian et al. Vacation? Yes, I recall that word ;-) I agree with most or all of your sentiments - that's why I was sceptical of adding it in the first place. I never advocated a heavy use of this object - it was only made as a handy tool for an application-program. I have a few comments in the opposite direction, though: Since I am not a programming-expert, I see two reasons for accepting an object if this size (which I agree is huge for the purpouse) 1) It is indeed a BrDataObject. This may be, as you comment, an unneceseary step taken to "hide" ROOT, but the way BRAT is structured right now BrDataObjects are a lot easier to handle - at least for the non-expert. 2) Using this object is an easy way of reucing file-size in other areas, since I can keep one or two variables and then throw away large chunks of raw data from the analyzed files. This in my view makes the rare use of a large object more than acceptable, since my computer is allready more than crammed with 100+Mb reco-files. > 2) Specialised classes is prefered. If you really need a summary > object of some sort, then you should make such a class. I agree this is best, but I fear we will end up with either classes that are huge due to keeping too many variables of infinately many small "utility"-classes for moving this and that information. > 4) There's a slightly odd but very simple way to store a simple number > in ROOT. Take a look at what Rene had to say on this: > > http://root.cern.ch/root/roottalk/roottalk00/2311.html Yup - this is more or less what I wanted. But: > His suggestion is perfect for debugging stuff and so on, but > probably not for production Agreed. It's also a bit non-intuitive for the unexperienced ROOTed BRAT... I still advocate having some capabitily within BRAT for handily moving small pieces of data, and I welcome a discussion as to how we should do this. For instance, referring to the example I gave in an earlier mail, storing the number of clusters in a TPC is not easily fittable in any of the classes. I could of course store the entire cluster-table, but that was what I was trying to aviod in the first place. Anyway - I agree that BrValueObject is not the best implementation of this. Learning from my previous mistake ;-) though, I won't remove it right away, but wait a bit to allow for further comments. Please respond, good people - I am sure there are quite a lot of opinions on this ;-) ------------------------------------------------ Bjorn H. Samset Master-student in Heavy Ion physics Mob: +47 92 05 19 98 Office: +47 22 85 77 62 Adr: Kri 2A709 Sognsveien 218 0864 Oslo
This archive was generated by hypermail 2b29 : Tue Nov 21 2000 - 03:47:56 EST