Hello ROOT Team,
Here is a small list, a wish list if you will, of some feature
enhancements that I wish ROOT would support. These are features that,
as a ROOT user, would make my experience with ROOT more productive and
enjoyable.
Would you mind commenting on these please? Perhaps you are already
working on implementing these features. Or, perhaps you have
specifically chosen not to implement them. Either way, knowing your
position on these features would be helpful.
1) Put the ROOT libraries into a namepsace.
Besides all of the other tremendous benefits of namespaces, this
would also allow the ROOT community to more easily share source
code. It also allows for selectively replacing bits of the ROOT
libraries with "fixed", "newer" or just "experimental"
replacements.
2) Instrument the ROOT libraries to optionally use exceptions.
Keep the error reporting mechanism currently used by ROOT
(i.e. procedural style return codes), but add an option (either
compile time or run time) which enables the use of exceptions.
3) Provide versioned interfaces to the ROOT libraries.
This would provide guaranteed binary backward compatibility so that
"old code" doesn't have to be recompiled with each new release of
the ROOT libraries. For those times when a version of ROOT wants
or needs to break binary backward compatibility, then this action
is guaranteed to be caught at link time, not at run time.
4) Provide a ROOT testsuite in the ROOT distributions (for both the
binary and source distributions).
This testsuite would be different from the files in ROOT's
"tutorials" and "test" subdirectories, although these files would
be a good place to start.
This testsuite should tell the user what is being tested for, what
the user should expect from the test, and finally the results of
the test.
Users should be encouraged to run a "make check" before a "make
install". A table of testsuite results for specific configurations
(e.g. hardware, OS, compiler, etc.) should be posted at the ROOT
web site.
5) Change the run-time "specify by character string" type resolution
mechanism to a template based mechanism.
For example, why not let a TTree dispatch on an object's type
(using the compiler), instead of forcing the user to specify an
objects type as a string?
I realize that some of these feature enhancements would take quite a bit
of work to implement. However, they would make ROOT more robust, easier
to use, and more user friendly.
--
Matthew D. Langston
SLD, Stanford Linear Accelerator Center
langston@SLAC.Stanford.EDU
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:38 MET