Thanks, that was the point I was trying to make! 2010/9/1 richard boaz <[email protected]>
> 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 > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
_______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
