> > What is meant by 'all objects' in this case? Correct me, if I'm wrong. It typically means 'all objects that have a name' ( and a title ), that means all objects derived from TNamed. I have met this problem, too ( my private opinion follows ). All root related objects could be divided into two groups. One group containing all NAMED objects and the other one containing ANONYMOUS objects ( that is NOT derived from TNamed ). Unfortunately ( and that's my private opinion ) quite a lot of important classes, existing in root framework, appear ONLY in the ANONYMOUS group. I would like to propose, that ALL classes ( o.k. almost all ) exist in two "versions" one without and one with name/title ( the problem here is, that only NAMED objects can be "found" by root when scanning subdirectories, for example ). Why ? I think I like the idea of building applications from loosely coupled "modules", each of them placed in a dll. Then, one starts the standard root executable, and loads all "extensions" that one needs ( just by gSystem.Load or ".L" ). The problem here is - how should these libraries communicate ? The best answer is - through "global" objects. I simply mean that the "module" "scans" subdirectories trying to find objects that it needs, and leaves the "intermediate results" for other modules in the same place. This requires, however, that all objects used to this communication are "findable", that is have a NAME. The first time I met this problem it was the TNamedObjArray class that did not exist, there exists only TObjArray ;-( . I would also like to propose another extension. It would be nice if root files could keep ascii files ( also compressed ), for example with c++ macros used to analyze/display other objects in the same root file ( or maybe with some calibration parameters ). Jacek.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:19 MET