Re: New API in 2.0.x ???

[Tim Janik <timj gtk org>]

On Wed, 16 Oct 2002, Owen Taylor wrote:

>
> Tim Janik <timj gtk org> writes:
>
> > On Sun, 13 Oct 2002, Owen Taylor wrote:
> >
> > >
> > > Sat Oct 12 21:30:41 2002  Tim Janik  <timj gtk org>
> > >
> > > 	* configure.in (GLIB_VERSION): up version number to 2.0.7, binary 7,
> > > 	interface 0.
> > >
> > > 	* glib/gstrfuncs.c (g_ascii_strtod): fix comment.
> > > 	(g_ascii_strtoull): new function, acting like strtoull(3) in the C
> > > 	locale.
> > >
> > > 	* glib/gscanner.[hc]: fix 32bit issues with integer parsing and
> > > 	support storing 64bit values in GTokenValue by
> > > 	using g_ascii_strtoull().
> > >
> > > I don't understand why these change (except for the 32bit issue) went
> > > into the glib-2-0 branch. They add new API, so they should be
> > > in HEAD only.
> >
> > strictly speaking, we got three API changes in stable CVS.
> > 1) g_type_fundamental_next() returns shifted fundamental IDs now
> > 2) GScanner gained v_int64 and store_int64 fields
> > 3) the addition of g_ascii_strtoull()
> >
> > (1) is required to get custom fundamental types back to work.
>
> Things were just broken here, so I don't think it was really
> an API change... what you got before was type ID's that were
> neither shifted or not shifted but somewhere in-between....

with 2.0.6 you can create one custom fundamental type if you
do the shifting, with 2.0.7 you'll have to not shift. so there
is an API change.

> > (2) is required to get 64bit scanning working beyond
> >     sizeof(long)==sizeof(gint64) type systems
>
> 64bit scanning is not a feature of GLib-2.0.0. It shouldn't be
> added in 2.0.x

neither is 32bit, which is why i was fixing the code.
not having v_int64 would mean that 64bit scanning works
on 64bit systems only, which is almost just as bad.
ideally, v_int should have been changed to guint64 before
2.0 and the parsing code be fixed. now we didn't do that (and
can't until 3.0), so i picked the next best solution which
is giving people v_int64 and fixing the parsing code. i don't
see a point in introducing an arbitrary limitation to 32bit
scanning until 2.2 for 32bit platforms.

> > (3) is not a necessary addition
> >
> > with (1) and (2) already causing an interface age drop to 0, i didn't
> > see much point in leaving (3) as a 2.2 addition.
>
> My concern isn't the interface age drop to 0, though I don't see it
> as necessary for (1).
>
> It's that we are adding unececessary new API to 2.0.x. Even if there
> are one or two necessary additions, it shouldn't mean that it is open
> season for adding other additions.

well, i did 3 API related changes, and you don't even give those
"one or two necessary additions". out of three items, you're
trying to argue one not to be an API change, another to be not
strictly necessary (sure, if 2.0.7 is meant to reproduce
scanning bugs from 2.0.6), and the third to be an unnecessary
feature (perhaps rightly so, but what's the point?).

however i won't fight endlessly over these issues, my time is just
to precious to be wasted with pointless debates over why perfectly
reasonable interfaces should _not_ be added to a library that
facilitates binary and interface age versioning.

>
> Regards,
>                                         Owen
>

---
ciaoTJ