Repository navigation
Better encapsulation of record metadata #371
Description
Activity
I agree that some restructuring of the Record class would be helpful:
Line 575 in 3c88d19
RecordInfo class for storing all the header data. Includes record and signal specification fields, and comments. rdheader will create this type.
It would be good to chat about this. I'm getting myself slightly confused about how these classes (e.g.
RecordInfofor header information andRecordfor data) would relate to the files themselves (e.g.x.heafor headers andx.datfor data).Having the top level p_signal, d_signal attributes is not my favorite, but I feel like it's rather pointless to have another object to capture these fields.
Side note, but it would be nice if these variables had friendlier names.
p_signal,d_signal,e_p_signal, ande_d_signalare pretty opaque.
Right now we have the
Recordclass with a huge number of attributes in the top level object. These attributes are varied, fall into many categories, and become very hard to keep track of.I also find it rather awkward that there is no separate 'header' or 'metadata' type of object. ie.
rdheaderandrdrecordboth return the same type of object.Initial idea:
RecordInfoclass for storing all the header data. Includes record and signal specification fields, and comments.rdheaderwill create this type.Recordclass for WFDB records. Theinfoattribute will be aRecordInfoobject.Having the top level
p_signal,d_signalattributes is not my favorite, but I feel like it's rather pointless to have another object to capture these fields.Open to suggestions.