Re: File name encoding and GTK ABI compatibility on Win32

Owen Taylor wrote:
I don't think anybody (including Microsoft) would exhibit windows.h
as an example of convenient, easy to use programming.

There are many, many things wrong with the Win32 API, but the ease of binary distribution you get with it isn't one of them.

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.

It doesn't prohibit it, things can just work better for apps that explicitly target the new GTK+ version.

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.

I don't see why it would be any more confusing than "Hey Bob, check out my leet new GTK+ program ... huh, it doesn't work for you?". Specifying the version of an API you want to target is a tested technique that works well.

As far as making a mess of the header files, I don't think it's such a big deal. It typically involves wrapping new functionality in an #ifdef. For Tors need, you could do:

#  define U(x) x ## _utf8
#  define U(x) x

void U(gtk_some_function)(GtkFoo *foo, gboolean bar);

This is slightly ugly, but not hugely so - it's still easily readable - and the portability gains are useful.

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.

I'm not really convinced by this - are there many examples of applications actually depending on this semantic creep? I can't think of any off the top of my head, certainly it should be the exception rather than the norm.

In the case that an app depends on stuff that was broken in previous versions, yes there is nothing you can systematically do about this. If apps depending on previously buggy stuff is so common that it affects library policy like this then maybe a longer beta cycle is needed to cut down the amount of buggy code being shipped.

thanks -mike

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]