Re: enforcing construct only properties and gnome-session
- From: Mike Hearn <mike theoretic com>
- To: desktop-devel-list gnome org
- Subject: Re: enforcing construct only properties and gnome-session
- Date: Wed, 14 Jan 2004 18:05:17 +0000
On Wed, 14 Jan 2004 14:25:03 +0100, Matthias Clasen wrote:
> I certainly think so, although the state of the GObject documentation
> makes it even harder to do the right thing when doing the wrong thing
> isn't prohibited. I think some CONSTRUCT_ONLY bugs were found in
> rhythmbox when Tim made that change.
I don't really understand this policy. Why not simply print a warning so
the developer knows they are breaking the rules? It clearly is a breaking
change as it breaks things - it just changes the semantics rather than the
struct/stack layout of an API. The interface of an API isn't always just
what is described in the headers, it's also what leaks out in terms of
bugs, laxness over the rules etc.
Users are going to work on the assumption that upgrading glib will not
break things, that's the point of being backwards compatible. If it's
possible to hang your system (X server but to the users same thing) by
doing that upgrade, then this is problematic.
Shouldn't stuff like this be opt-in at the API level with something like
gobject_enforce_rules(2.4), rather than opt-out? Perhaps some
finer-grained versioning than what is currently used is needed. For
instance, the headers restrict you to the features available in GObject
2.0 unless you specifically do:
#define GOBJECT_USE_VERSION 2.4
at which point the new functionality becomes available *and* the semantics
of functions change. That would also help developers who wish to ensure
their software works on older versions but don't want to/can't check each
call they make in the docs (perhaps they inherited a codebase).
This is still rather dodgy: the best way IMHO would be to mark the old
call as deprecated and make a new one with a 2 suffix if the change really
can't wait for a new major version, to make it clear that there was a
breaking change. That way things don't change behind the developers backs.
If this has already been discussed and discarded as a bad idea, or if it
already exists and I simply never spotted it then you have my apologies.
thanks -mike
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]