Hello Tim, Tong, Blast,
Tags:
Could we "tag" this version of BlastLib and blastmc?
I think we are on the cusp of a lot of modifications of the code, so it
would be good to have a version tag. I noticed that there does not seem
to be a uniform scheme for naming tags. The blastmc has a "v1_x" sheme,
the BlastLib a "March2001" scheme. I think a uniform tag scheme for all
libraries and associated CVS (Blast_Params) would be good. I prefer
something that does not include the data, so would go with Vx.x.x,
starting with V0.1.0. But I am open to any scheme that is consistent.
Raw Data Class:
I agree with cleaning up the naming scheme as you suggested. I am much
in favor of a TBLRaw class, that includes some of the methods needed to
manipulate the raw contends.
I do not think that there is a big problem with keeping every field in a
class "public". What we need however is methods in those classes that
wrap the array allocation, retreival and put operations etc. This allows
for safer code, and if there is too much of a performance hit in always
checking bounds etc, we can even have a compilation option that turns
off all the unnecessairy safety. An important question that would need
to be answered is what are the access requirements to the "TBLRaw"
class? I.e, what kind of puts, retreives, sorts does the class need to
implement?
I have not seen Tong's new implementation but it sounds like that is a
different way of organizing the raw data. What I can not tell is if a
TBLHit copies the information from the current "raw" structure, or of it
"points into" the raw arrays.
If we write a TBLRaw class, this would impact TBLHit (and others), since
there will no longer be a pure C style array, thus no way to point into
that array. One good way of organizing the classes would be to have
TBLRaw deal with all the direct interactions with the raw data. A TBLHit
or TBLSegment that needs direct access to this data could derive from
TBLRaw, thus extending the functionality of TBLRaw in a specific way.
The same for other classes that need direct access to the raw data.
Cheers,
Maurik
On Mon, 2001-10-01 at 10:29, Timothy Smith wrote:
>
> Hello Maurik. Tong and all BLASTers,
>
> As Tong pointed out, TBLRecon was written when I was just learning
> about C++. I do think that the entire class should be replaced.
> perhapes this should start out with the creation of TBLRaw. At present
> the raw structure is part of TBLEvent.
>
> TBLRecon is also overloaded. They is also now all of Tongs
> code. Perhapes we need some reconstruction class naming convention
> to use these multiple developements, something like
>
> TBLWcRecon, etc. ...
>
> Tong has used,
>
> TBLHit, TBLHitContainer, TBLCluster, TBLClusterContainer
> TBLStub, TBLStubContainer, TBLSegment, TBLSegmentContainer
>
> already the scintillators and cerenkov have been split off into,
>
> TBLScRecon & TBLCerenkovRecon
>
>
> If left to myself I would migrate the best parts of TBLRecon
> into TBLWcRecon, with the raw data in a class TBLRaw.
>
> In Tong's design there is a TBLHit for every hit, and
> TBLHitContainer is a collection of the hits, plus the methods to
> find the hits. The same is true for Clusters, Stubs and Segments.
>
> Any ideas for a convention to deal with this multiple
> developement tracks?
>
> Tim
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST