Closed ropg closed 3 months ago
It now does not take arguments anymore and does things internally
The the fewer the parameters, the better 👍
However, breaking public API is not something that we take lightly. We could keep the old function in the API for the time being. It could print a deprecation message to serial and delegate to the new function?
I'm not so sure I can think of any scenario where the user would want to interact with either drawLogBuffer or setLogBuffer. Maybe we should rename them to something that's private or protected and print deprecation msgs for both?
"deprecated: print functionality now handles buffer management automatically" ?
Whatever we do, we can't remove functions from public API without a major version bump. Hence, I suggest something like
bool OLEDDisplay::setLogBuffer(uint16_t lines, uint16_t chars) {
Serial.println("[deprecated] Print functionality now handles buffer management automatically. This is a no-op.");
}
setLogBuffer()
can then be made private API I guess.
It occurred to me that it's maybe cleaner to have cls()
and setFont()
remove the buffer and then only the next print action re-set it as needed. That way users have the option to free the memory by just issuing cls()
. Will make it all so later today.
This looks sane, thanks a lot.
setFont
happens, as this changes the number of lines and chars. It now does not take arguments anymore and does things internally and is clearer about when it gives up.