> ( ... ) > Ideally, it would be nice to always derive from TNamed instead of TObject. > However, for performance reasons, we want to keep the two modes. > There are many objects that are only transient objects and they may be > created by millions. > In ROOT most high level objects are always named objects. The name > is in general given in the constructor. There are a few exceptions like I have nothing against keeping "two modes". It's clear for me that one needs them "for performance reasons". However, due to the same "performance reasons" I would like to use ( sometimes ) NON "high level objects", and they are NOT "always named objects". Thus I don't propose to remove "anonymous" classes. I rather propose that all ( or almost all ) classes, including VERY LOW LEVEL classes, are provided in "two modes", one "anonymous" and one "named". > ( ... ) > Agree with the principle. Note that gROOT->FindObject(name) can already be --------------------------------------------------------^^^^ Am I right here - this works only for named objects, not for anonymous. > used for this purpose. We could extend the functionality of this function > to behave like a Unix search path mechanism. I would say - an option for FindObject ( "R" for Recursive ). The default should probably stay - searching in the currect directory only. > ( ... ) > We already have a class called TSystemFile. One could imagine something like: The new class TMacro proposed by Valery Fine ( in a separate mail ) looks nice. > What should happen when: > - Interactively the command Root > asciifile.dat is typed ? or > - TSystemFile *sfile = (TSystemFile*)gDirectory->Get("asciifile.dat") > the file may already exist on the local system ! Well, if one clearly sets the rule, that the first object found with the given name will be used ( and if the serach process looks first in opened root files ) ... > ( ... ) > What about non-ascii files (example a GIF file) ? Why not ? As Valery Fine writes : > In fact this way the source of ROOT itself (or any other ROOT-based > application) > may be kept with ROOT file and installed from there too. Maybe a new ROOT-based configuration/build system :-) ? Jacek. P.S. On this occasion I would like to propose another extention. Valery Fine proposes : ... TMacro::Load(); // Aka .L command of CINT ... TMacro::Compile(); // Invoke the local compiler and produce the local DLL (share lib) ... I would like to propose, that both ".L" and "TSystem::Load" are more user friendly. What I mean is, if I write ".L MyClass" ( note - no file name extention used ) it should try to find a shared library with this name ( ADDING the proper dll file name extention for the particular OS ), and if not found it should try to load a source code file ( ADDING the proper c++ file name extention ".C", ".cpp", ... ). ( Don't ask me what should happen if the source code file is newer than the shared library. ) Jacek.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:19 MET