Re: GNOME Namespace Management - ARC & GNOME
- From: Sean Middleditch <elanthis awesomeplay com>
- To: desktop-devel-list gnome org
- Subject: Re: GNOME Namespace Management - ARC & GNOME
- Date: Thu, 16 Dec 2004 10:54:42 -0500
On Thu, 2004-12-16 at 14:46 +0000, Mike Hearn wrote:
> On Wed, 15 Dec 2004 16:57:11 -0500, Sean Middleditch wrote:
> > How would they know? Why should they _have_ to know? If
> > they install Linux Weekly Distro V56, then install FooApp, then upgrade
> > to Linux Weekly Distro V57, FooApp should not break.
>
> I think the exception to this is when the app is clearly breaking the
> rules, or worked through sheer fluke.
Yes, that's a different story. I should have been a bit clearer. ;-)
When apps using only the public API break, *then* there's a problem.
The documentation, however, has to be up to snuff - if there's no way
for developers to easily identify public vs private, there is a problem.
Which is the topic this thread started over, iirc.
If the API and library are built right, you can make it (practically)
impossible to depend on internal API. Headers included by the apps
shouldn't include anything private (GTK does this already rather well)
and the libraries should only export appropriate symbols.
There is then apps that depend on broken semantics, but that's life.
I don't expect the GTK developers to avoid breaking apps that were
already broken. That wouldn't be fair or realistic.
Once GTK publishes an API, however, I expect it to never break. Most of
the minor stuff I see where it does is because developers don't want the
"ugliness" of having two sets of functions that do _almost_ the same
thing, that sort of stuff. My only advice there is to just suck it up,
provide both sets of functions, and clean up the cruft in the next major
release.
Users will thank you. You will get groupies. There will be much
rejoicing. Followed by lite salad.
--
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]