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.
What about using something like hd44780 instead of LiquidCrystal for the basename of everything?
That way the library is totally separate and insulated from the LiquidCrystal library and
can even coexist, which makes it easier for users to add without breaking any other
existing sketches they may have that currently use the LiquidCrystal library.
Yes, I think you have a fair point here. The basic idea was to create a drop-in replacement to the LiquidCrystal library. The problem is that the LiquidCrystal library was never thought out to be extendable. Therefore, the first thing I did was to virtualize some of the methods of the original library and create a sub-class to implement the access details. However, the class hierarchy looked very strange.
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 sketch
I 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.
It would make it really easy to also add in support for using a shift register or a SPI interface:
Google Code Archive - Long-term storage for Google Code Project Hosting.
I will download the library and give it a shot at porting it to this new structure. This would certainly enrich the port folio of the library.
Name required for the new library. HELP appreciated to its naming. The library (and base class should be easy to remember, descriptive of what it does).
What do you think?
Cheers,
Paco