2010/9/1 David Nečas <yeti@xxxxxxxxxxxxxxx>
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?).
On Tue, Aug 31, 2010 at 10:38:13PM +0200, Milosz Derezynski wrote:I am not against changing the function prototype. However, the
> 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.
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
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 gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
