2010/9/1 David Nečas <[email protected]> > On Tue, Aug 31, 2010 at 10:38:13PM +0200, Milosz Derezynski wrote: > > Well, to be honest, the g_ stuff serves as an abstraction layer; I don't > > think that currently there is any problem with using the plain C type > > instead of the g_ type in this (or other) functions, but for > consistency's > > sake and for the case that this typedef will become more complex > depending > > on other platforms supported in the future I would consider this a minor > bug > > and opt to get it fixed. > > I am not against changing the function prototype. However, the > reasoning that the typedef can change is bogus. The type is equivalent > to the C type and has been always specified so: > > Types which correspond exactly to standard C types, but are included > for completeness - gchar, gint, gshort, glong, gfloat, gdouble. > > A typedef to something else would be a major API breakage. > > Yeti >
desiring consistency is never a bogus reason. making it right now, since, as you say, it is currently equivalent, would cause no API breakage (what breaks exactly?). when, and if, the typedef wrapper ever does need to change, this would indeed result in API breakage. better to fix now when no harm possible, rather than waiting till a necessary change necessarily breaks the API. the longer into the future that the typedef remains unchanged, the less likely it will cause harm in old code. or, why should it remain wrong just because it wasn't right in the first place? i.e., this "wrongness" works now, but is not guaranteed to work forever. richard
_______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
