Re: Which objects are stored by TFile::Write()?

From: Jacek M. Holeczek (holeczek@clri6g.gsi.de)
Date: Mon Jun 02 1997 - 13:37:53 MEST


> ( ... )
> 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