James McDonald wrote: >>> Yes, in an ideal world there would be a stable API for everything, >>> and new versions would not be a big problem. Pigs will fly first. >> >> In the interests of equal time, "the rules" allow breaking >> compatibility between major revisions, and the jump from 1.x to 2.x >> certainly qualifies as a major revision. It would be nice if greater >> effort were expeneded to ensure backward API compatibility. > > I noticed that in some of the backwardly compatible API's developers > are saddled with the good and the bad from a previous implementation > and the extra effort to maintain compatibility. > > Doesn't the re-implementation of certain API's help to create what > could be a great leap forward when the newer version comes out > > I'm not a developer but isn't gtk2 far superior to gtk1.x?
Backward compatibility is fine, as long as it doesn't limit you. How long did Windows really have DOS as its base because of backward compatibility and how long did that hold back *real* PC advances? [How many of you fought the "extended memory" wars to get around 640K?] One working method of advancing while maintaining the API backward compatibility is to "deprecate" functions -- to mark them as no longer the approved method, and flag them as a warning in the compiler, but continue to honor them. You provide the "new" function with a different name, and you write the API the way you now think it should be, but you don't remove the old one. The documentation should also include a link between deprecated functions and the new functions that should replace them. See the Java development model for examples of this. Tom :-}) Thomas A. Condon Plain Text Emails Don't Spread Virii! _______________________________________________ Linux-users mailing list [EMAIL PROTECTED] Unsubscribe/Suspend/Etc -> http://www.linux-sxs.org/mailman/listinfo/linux-users
