The bigger/real issue, which I think Jacek may have been hinting at, is that it is better to program to small, well defined interfaces that don't change, rather than to the class itself. Combining multiple virtual inheritance with pure virtual classes is one way to support this. Although a C++ header file containing a class definition (e.g. TTree.h) is often called an "interface", it may or may not be a useful interface (and often times poorly designed classes expose harmful interfaces), because the C++ language itself doesn't encourage the design and use of well defined interfaces. Speaking to your example, Java can only survive without MI because of its support and encouragement of "real" interfaces. If one uses the Java libraries in ones projects (which we all do at some level), we are forced to use interfaces prolifically. Continuing with the TTree.h example, one can observe many, many interfaces just crying to be independently exposed. However, TTree.h has always exposed just one "interface", but it is littered with inlines, public implementation inheritance, method and member additions and deletions, signature changes, etc. In this example, the class TTree basically has a new interface for each new release of the ROOT libraries (which is why client code must be recompiled and relinked with each new release of ROOT). The "pure C++" solution to providing interfaces is combining multiple virtual inheritance with pure virtual classes. Until I read your email Victor, I wasn't aware that CINT didn't support multiple virtual inheritance. If it weren't for this fact, then I would disagree with you that ROOT must avoid MI. If MI is used properly (i.e. to expose interfaces to clients), then I would argue that ROOT should use MI. However, since the C++ language doesn't provide the support and encouragement to use it properly, then I agree that it is usually best avoided. I don't mean to pick on the ROOT Team, because most C++ users either don't know how, or don't take the time, to design good interfaces to their libraries, and the C++ language offers no support for this. The ROOT libraries in general expose poor interfaces compared to well designed libraries (don't just take my word for this - make the measurements yourself by running any code metric on the ROOT source and you will see what I mean). I would suggest adding only QC to to the ROOT 3.0 wish list, which would include: 1. small, well designed interfaces 2. a test-suite 3. code clean-up 4. no new features Regards, Matt ----- Original Message ----- From: "Victor Perevoztchikov" <perev@bnl.gov> To: "Rene Brun" <Rene.Brun@cern.ch> Cc: "Jacek M. Holeczek" <holeczek@us.edu.pl>; "roottalk" <roottalk@pcroot.cern.ch> Sent: Thursday, September 28, 2000 7:32 AM Subject: Re: [ROOT] v 3.0 wish list > > Sorry, I missed your point. You want to use multiple virtual inheritance. > > Before doing so, we have to evaluate all possible consequences and > > side-effects. > > The obvious side effect is CINT. I have already met with this. > If you create an object in CINT, pointer to it returns as long. > When outside it casts to TObject it is completely wrong (in case of > multiple inheritance). I do not see how it could be solved. > So we must avoid multiple inheritance. > Anyway, if Java can survive without it, why we can not? > > Victor > > Rene Brun wrote: > > > > Hi Jacek, > > Sorry, I missed your point. You want to use multiple virtual inheritance. > > Before doing so, we have to evaluate all possible consequences and > > side-effects. > > Coming back to your question in 1997 (::) , this problem is now solved > > since all collections can be named. Use TCollection::SetName > > when you want to name a collection. (and GetName). > > > > Rene Brun > > > > On Wed, 27 Sep 2000, Jacek M. Holeczek wrote: > > > > > Hi, > > > This is a very old story ... . It began in year 1997 : > > > http://root.cern.ch/root/roottalk/roottalk97/0086.html > > > As you can see it is often difficult to build a user's class from more > > > then one root classes, especially these more sophisticated. This could be > > > cured by making some of the most "basic" classes virtual (TObject, TNamed, > > > ... any other ... ?). > > > Jacek. > > > P.S. Of course this can also be solved by the user if she/he writes a lot > > > of her/his own code, but ... I would prefer some "code > > > re-usability". Jacek. > > > > > -- > Victor M. Perevoztchikov perev@bnl.gov perev@vxcern.cern.ch > Brookhaven National Laboratory MS 510A PO Box 5000 Upton NY 11973-5000 > tel office : 631-344-7894; fax 631-344-4206; home 631-345-2690 >
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:34 MET