On Mon, 2004-12-06 at 11:16 +0000, Mike Hearn wrote: > Owen Taylor wrote: > > I can't think of specific examples in the past (though we've never > > supported compile-on-newer, run-on-older), but there is certainly > > another example for 2.6 ... g_return_if_fail_warning(). > > Things like the GDK_THREADS_ENTER change, would be an example. Ah, yeah, there's an example. > > I don't see constraining ourselves to support compile-on-newer > > run-on-older. There's a lot of useful stuff that that prohibits. > > How does it prohibit anything? All that needs to be done is making the > new functionality opt-in. Windows has used this technique succesfully > for years. I don't think anybody (including Microsoft) would exhibit windows.h as an example of convenient, easy to use programming. What it prohibits is making things "just work better" ... the g_return_if_fail() change saved on the order of 5% code size for GTK+. That's a pretty huge win. Having to put -DSMALL_RETURN_IF_FAILS on your compile line (along with 15 other things) would be unspeakable. Having to put -DGTK_ABI=2.6 would still confuse the heck out of beginning programmers, and cause a big mess in the header files. If people want their programs to have a prayer of working with older versions of GTK+, they need to be testing extensively with those older versions. (It's not just functions and enumerations that get added. There's also semantic creep where combinations of function calls that didn't used to work start working.) And at that point, we might as well say "compile with the oldest version you want to run with. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part