Re: gir stability

Ryan Lortie <desrt <at>> writes:

> We need to figure out what our story is with respect to annotations.
> 'Rename to:' is an extreme example (since an entire function, as named,
> disappears) but we can easily cause problems just as serious with
> changes that look a lot more innocent (like changing array length
> parameters or such).  We can even break vala bindings with the
> introduction of an (allow none).
There's been a bunch of changes that people have often done to stable APIs in
various projects and have been happy that this works without problems. Examples
that I can remember off the top of my head include:
- constifying arguments to functions (in particular strings)
- allowing NULL inputs
- changing void return values to booleans (or even ints)
- adding arguments to vfuncs (not signals, regular vfuncs)
- renaming arguments

And there's probably a bunch of other even uglier things that people enjoy
doing. And I'd be very unhappy if those would get even more restricted than ELF
already makes them for us. So I'd take a very hard look at Vala and wonder if
disallowing nullability changes isn't a bug in Vala.

That said, if things like this were introduced, I'd want a tool to check for
this. Because when people in C start passing NULL before the Vala guys figure
out that that breaks their applications, we have a big problem. And the only way
to not have this happen is by a tool telling us "you are breaking API" -
preferably during make, but at the latest upon make distcheck.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]