Christian, I will reserve comment until I hear from mult guys. As said, I agree with eliminating BrClonesArray. BrDataObject had nothing to do (in my mind) with the fact that we were not 100% committed to root. It is a common BRAHMS data base class. Since TString stuff has been fixed, we can migrate out of that and have it once again inherit from TNamed if that is too much overhead, but not get rid of it. I feel it gives us more if we have a common base class that we derive all of our data classes in event nodes from. If we don't do that and need some extra functionality, then we have to appeal to the root guys to put it into TObject. On the tag in BrEventIO, I heartily agree. In fact I have done nearly the equivalent of that when I imported BRAT stuff to use with NIMROD here at TAMU. I had the advantage of hindsight when doing that. On the other hand, it would seem to me a simple change in the streamer to implement that. I have been thinking to do it, but as you know BrEventIO is such an important class that I am afraid of touching it for breaking it. So I have not put that tag class in. But with proper testing, it should be possible with no loss of backward compatibility. Regads Kris Christian Holm Christensen wrote: > Hi Kris et al, > > On Tue, 08 May 2001 09:26:35 -0500 > hagel@comp.tamu.edu wrote > concerning ": Re: Proposal to change BrSiRdo and BTileRdo - once again!": > > Christian, > > You indeed risk your neck!!! > > Why can the streamer not be simply changed to write only relevant > > data? > > Fixing the Streamer method is not an option if we want to use ROOT 3 > schema evolution. > > > As far as I can tell, that would accomplish what you want to > > accomplish regarding disk space and it would keep backward > > compatibility. > > Even if we fix the Streamer, you're not at all guarantied backward > compatiblity. I recently had a problem reading files created with > BRAT 1.15.6 with BRAT 1.15.3 (both ROOT 3.00/06), and it seemed to be > related to BrDataObject fName and fTitle members, and that class has > not been changed since BRAT 1.13.2. > > Also, to do a fix so that the streamer will only write out the data > needed, I'd have to break compatiblity explicitly. In BrTileRdo and > BrSiRdo we use fixed sized arrays. This would have to be changed to > dynamical arrays and the introduction of another array to hold channel > numbers. > > > On the issue of backward compatibility with brat_v2, I do not yet > > see why it is going to break assuming I get my way and we don't > > change names of classes. > > Well, if we want to use ROOT 3 schema evolution, which I believe we > agreed upon and I think is a bloody good idea, then backward > compatiblity of reading BRAT1 generated files will be broken > explicitly. > > Also, we should not have BrEventIO write it self to disk, but rather > have a special "tag" class for that purpose. This is to avoid some of > the headacvhes we've previously had with modules having non-zero class > version number. > > In fact, renaming of classes is the least of those wories. > > > I admittedly have not read everything, but I have been using brat_v2 > > since the beginning of the year with root_v3 and I am reading > > everything I have tried and it works. > > Yes, but you haven't used ROOT 3 schema evolution, and have not > introduced a "tag" class for files. So, in essence the only > difference in ROOT that you'd see is the "const"ness of methods, and a > few other minor changes. > > Also, I think you'll find in some of the recent emails compelling > reasons for explicitly breaking backward compatiblity (not just from > me mind you). > > Uh, sorry Kris, for flooding you in emails these last few days. > > > Will the fact that they not inherit from BrDataObject not break > > other things and break BRAT programming specifications? > > Since you'll never store one of the proposed classes directly in a > file, but always as an array element in BrTileRdo, that is not really > a problem. > > There's a further problem with BrDataObject, that it has a huge > overhead, in that the title is hardly ever used (but of fixed size - > 64 bytes), and the name is far too long (64 bytes too). In short, I'd > really like to do away with that class. > > I understand that it was made at a time when we were not sure wether > to commit ourselves to ROOT or not, and so you masked most ROOT stuff > (like BrClonesArray). Now, I believe it's safe to say that we are > 100% commited to ROOT. Also, with ROOT 3, a TNamed derivied class > can easily be stored in a TClonesArray. > > > I consider this a huge outcry, but would like to hear what the mult > > people have to say. > > So would I, but I'd also like for you to comment on the above. > > Yours, > > Christian ----------------------------------------------------------- > Holm Christensen Phone: (+45) 35 35 96 91 > Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 > DK-2200 Copenhagen N Web: www.nbi.dk/~cholm > Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Tue May 08 2001 - 11:57:03 EDT