> > > Regarding the question of providing a migration path, IMO it's > > oftentimes easier to keep a deprecated class around for awhile, > > as opposed to some methods. Here that means renaming the > > existing Fl_Input to Fl_Input_Deprecated (or something) while > > making the proposed changes to Fl_Input. I think that makes > > it easier for affected developers to migrate, because the > > change is more centralized. I haven't got any hard evidence > > to support this claim of course, it's just sort of a gut feeling. > > -1 on this proposal. Everyone's code would break, and they would > be forced to either rename all use of Fl_Input to Fl_Input_Deprecated, > or update the method calls to the new interface. > > D.
One way or another, at some point following the API change, code that uses Fl_Input(int, int) to set the text insertion position is going to be broken -- it will have to be updated to use the new interface. (Code that doesn't do so is unaffected). The question in my mind is how best to help affected users get from point A to point B. To that end, I feel like it would be nice to be able to say something like "if your code breaks, you can just replace this class with that one until you get a chance to hunt around for the method calls that you have to change." Just one man's opinion :) Best, Stan _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
