Adding a 'deprecated' warning would affect other jallib samples. Our group does not allow any warnings, so build bot would fail.
Instead, I am thinking about taking old code out of glcd_constants, and put it directly into the older glcd lib files so I don't break anything. I'm not sure yet though, I have to look into it and it all needs more thought. especially fonts. Matt. On Dec 16, 1:56 pm, Rob Hamerling <[email protected]> wrote: > Matt, > > On 2010/12/16 18:26, mattschinkel wrote: > > > Because the old procedure is named lcd_line(), and I can't change it > > because ks0108 and nokia3310 both use it. I agree that it should be > > glcd_ > > Since I don't use such graphi screens (yet) I have not a strong opinion > about its contents, but I have a comment on backward compatibility. I > agree that in general we should try to keep the API unchanged. But there > are limits, it should not become burdensome. When the library becomes > too artifical only for backward compatibility then a the limit is > reached (but of course 'too artificial' is debatable). > When is only a matter of the name of a function or procedure you can > easily provide a temporary alias. Have a look at lcd_hd44780_common.jal: > at the end you'll find some procedures to overcome a name change. A > program can use the old name, but a 'deprecated' warning is issued and > the procedure with the new name is executed. Even parameter changes > could be supported this way. > With this technique a gradual migration path is created: a programmer is > stimulated to use the current names, but older programs can still be > maintained without having to migrate to new names. > > Regards, Rob. > > -- > R. Hamerling, Netherlands ---http://www.robh.nl -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
