SacDataHdrs should be a subclass of SacIO

[smlloyd]

SacDataHdrs seems to do mostly the same as SacIO, so perhaps we should either try to replace the SacDataHdrs bits with SacIO or SacDataHdrs should be a subclass of SacIO to prevent code duplication?

[xlougeo]

I created SacDataHdrs mainly to hold the data and headers in memory, because SacIO saves any changes to the file instantly. For example, It's typical to experiment filter to seismograms, and would rather save filter parameters to header, keep the original data unchanged, work on filtered data in the memory. Can a subclass of SacIO do that? Another thing is to allow more flexibility of the data structure. I remember you were thinking about a totally new data structure for seismic data. Maybe that can be a new wrapper for SacIO.

[smlloyd]

I figured the "directly saving changes to disk" is why you made SacDataHdrs. I also didn't like that, and the current implementation of SacIO does keep data in memory without writing to disk. Moreover, you can add arbitrary attributes to an instance of SacIO (they are, of course, lost when writing back to a sac file).

With that in mind, as a subclass SacDataHdrs only needs to do stuff that isn't already in SacIO, and all the copying data and headers from an instance of SacIO to an instance of SacDataHdrs can be removed from aimbat.

[xlougeo]

Yes, that would be good. Keep an eye on some parameters such as filter are saved to sac headers K*