Description
@dtcooper @pR0Ps
I would like to start discussion about general change of the FitFile architecture, already started in #61 and #57. The problem is speed, code simplicity vs. feature richness.
IMO is may be solved by the decorator pattern, e.g. see this example on python.org. (It's not exactly same as Python decorators, but the Python decorators may be used to implement that.) I think the main method is FitFile.get_messages()
which should yield
message by message. The other decorators has to implements get_messages()
and may add further functionality.
Example: MessageCacheDecorator
. I have proposed in #61 to remove message caching from the FitFile
. Then a new class MessageCacheDecorator
may be created. So, users, which would like to keep the old functionality would do just:
fit = FitFile(...)
fit = MessageCacheDecorator(fit)
m1 = fit.get_messages(...)
m2 = fit.messages
Similarly to the data processors. Each conversion may be a decorator, too. So, it does not need to be in the FitFile
core. And, if you really need to keep BC, the FitFile may be split to: FitFileDecoder
and FitFile
just as a decorator (or subclass) to FitFileDecoder
.
Activity