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?

-- 
PHP-GTK Development Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php