GTK Ticked-Off

[Alma J Wetzker]

Condon Thomas A KPWA <tcondon at kpt.nuwc.navy.mil> Wed, 10 Sep 2003 
09:53:22 -0700
> 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