* I worry about the simple constructors here though. I believe that
causes things to be instantiated on the stack which is then blown
away. That would mean that I would need to rely on the heap with
the new keyword, but if I do that I will need to deallocate later.
* Digging into DS3232RTC, it looks like it has no deallocator, and I
kind of suspect the same for Rtc_Pcf8563. Either way, we will want
to ensure that we can delete those classes where we need to. I
would hate to introduce a memory leak somewhere on something so
small
* My current understanding of the WatchyRTC class is that it came about
due to the need to ship Watchys with new RTC chips. The class here is
designed to accomodate both chips
* This class is a good way of doing just that--a single spot that
hides the implementation details of both chips. The downside to this
approach in the moment is that we have a bunch of conditionals that
check if we have this or that chip, and if we ever need to support
yet another chip, we will have an even more complex WatchyRTC class
* I am going to refactor this to simplify it so that way we will not
have to worry about modifying this much if we need to support a new
chip, or if someone else wants to support a new chip
Andre LaFleur
sqfmi