Re: Re: [php-gtk-cvs] cvs: php-gtk /ext/gtk+gtk.overrides

Pablo DallOglio wrote:

Hi, My apologies, I haven't realized these changes at that time. I don't see any problem in changing things that aren't widely used like IO stuff. But datagrids are a central part of every application, like forms and we have many samples on the internet about its usage and printed material also. I know a simple "grep" or a "rpl" does the work (no need for scripts Elizabeth), but it opens precedents. If we change these constants today, we will be changing method names tomorrow and we'll start having incompatible versions among the same encarnation of php-gtk2... And this makes me really worried. Bob told us there souldn't be books about php-gtk because there is not even an stable release. But since the API was defined and we just needed a major API coverage, there was no reason to delay this. I believe that a techonogy need good developers to become a sucess but need evangelizers also.

Actually, if you look at other language wrappers, you'll see they all have their constants for gtypes in gobject as well - take a look at pygtk and perl's GTK2 and ruby's wrapper - why should PHP be the only ones putting constants from GLib in C into the GTK namespace? By the way, this isn't the first change that has happened, and we have "changed method names" - there were quite a few just between the alpha and the beta. The point is to have an intelligent API that people coming to PHP-GTK2 from other GTK implementations will understand - as well as creating an easy to use tool for those who come from the PHP community. Why are we worrying about BC with alpha and beta versions?