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.
I don't see how backward compatibility is a limiting factor. (I have needed to maintain and upgrade libraries and API's in a business setting.) The tasks you need to accomplish are largely the same, no matter the version. New functions are always new and create incentive for the new library. Why do the function calls/parameters need to change at all? If you need more/fewer parameters or to change the name to make it fit into a naming scheme, you simply keep the old call as a call to the new function (preserving assumptions for parameter changes).
The examples of DOS or LIM/EMS/DPCI are not germaine. Those legacy relics existed either because a proprietary scheme was trying to take control of the technology or because development focus resisted changing of underlying structure while advancing on other fronts (working on interface while keeping DOS vs fixing OS for stability) ((Yes I know, stability != Windoze, but that was the goal)) In the case of memory wars, several products soon came out, using the 386, that supported ALL memory access schemes.
-- Alma
_______________________________________________ Linux-users mailing list [EMAIL PROTECTED] Unsubscribe/Suspend/Etc -> http://www.linux-sxs.org/mailman/listinfo/linux-users
