fm:
Hi Bill el al.,sorry I didn't answer before. You have raised very fair points in your previous post, I will do a cut and past from the previous post to answer and keep in one place the library discussion.
I can also see that people will not like to replace the current LCD library and when they compile find out that it doesn't. To be fair, I think that I will rename this library and try to create a "compatibility define".
Mind you, this is not an easy task, since to be fair, the LiquidCristal class would have to be the base class to all 4 bit objects and also to be used as a virtual class.
If the intent is to replace the LiquidCrystal library, then, IMHO, I think it is important
that it be a drop in replacement and still allow existing LiquidCrystal sketches
to continue to compile without having to make any changes, even if it is as simple
as updating the constructor names in the sketchI think that the easiest thing to do is:
- Rename the base class to something . I would appreciate all your help here. Something that is easy to remember and descriptive of what it does (I had "LCD" in mind).
- Rename the current LiquidCrystal_4bit class to LiquidCrystal.
This would simply give you full compatibility with the current library and be able to use the extensions differently. In this case, the library would be a simple replacement without having to change a single line of code.
I think I'd try to keep the separation and not rename anything LiquidCrystal.
Not sure what the real answer is for a new name because even the name LCD may not be clear enough
I've seen people get confused and call both text and graphic devices a "LCD".
(I'll use the name hd44780 in my examples below)
I think the key to providing backward compability.
is how to transparently map the existing LiquidCrystal constructor name in their source code
to the new libraries constructor name.
i.e. you don't necessarily have to actually rename the hd44780_4bit constructor to "LiquidCrystal".
You just have to recognize that constructor name or transparently map it to your new name.
After that, since all the API function names
in the new class match the old class it is all transparent.
So, I think you could have a a set of headers that all use something like hd44780 and then
have a LiquidCrystal.h header file that might look like:
#include <hd44780.h>
#include <hd44780_4bit.h>
#define LiquidCrystal hd44780_4bit
An alternate method might be to have a constructor named LiquidCrystal in the hd44780_4bit.cpp module
that can be enabled with a special define.
In that case the LiquidCrystal.h header would include the 2 hd44780 header files as above
and turn on the special define to enable the LiquidCrystal named constructor.
I don't believe that it can be done using only a simple define in the new headers
to turn on a 100% backward compatibility mode because
to have full 100% backward compatibility, the header file LiquidCrystal.h has to exist because that is what
the existing code that uses the LiquidCrystal library includes.
And if a file called LiquidCrystal.h exists in this new library,
then this new Library cannot co-exist with the current LiquidCrystal library as it
will confuse the IDE or worse the include path points to both directories and its not clear which LiquidCrystal.h header
is included. (the original one, or the one from this new library)
It is a total catch-22.
I don't see that this issue can ever be resolved.
There are essentially 2 choices
- total replacement of existing LiquidCrystal library and have a new fully backward compatible library
(which requires removing existing LiquidCrystal library) - A new library named something like hd44780 that lives side by side with LiquidCrystal
The 2nd case is probably easier to swallow for people. This also removes any backward compatibility issues
for the new library as old/existing code continues to use the existing LiquidCrystal library and new applications
will simply include the new hd44780.h and then the appropriate hd44780_xxx.h header for the particular hardware.
Also, any existing application that is to be converted to using the new library will simply require a few small edits
to get the includes and the constructor names set up correctly.
Another possibility might be still going with option #2 above but also
to ship the new library with something like a dummy/masked LiquidCrystal.h
backward compatibility header that is named something like LiquidCrystal.h.compat
(to avoid any name collisions with the current LiquidCrystal library and hide it from the IDE)
that contains the includes and mapping defines kind of like what was shown above.
Then provide instructions to people that want use this new library as a full replacement for the existing LiquidCrystal library with
how to do that.
(By simply renaming the LiquidCrystal.h.compat to LiquidCrystal.h and removing the current LiquidCrystal library.)
Just some ideas...
One big thing I noticed that I think is a real deal killer is that the library code currently only works with the Arduino 1.0
pre-release code and does not work with the pre Arduino 1.0 environment.
There are few places that need to check the value of ARDUINO < 100 and then include <wiring.h> rather
than "Arduino.h> and then the write() function needs the same conditional and either return vode or a size_t
BTW, very cool that the shift register code is now in there.
--- bill