[haiku-commits] Re: haiku: hrev48216 - src/apps/showimage src/kits/shared headers/private/shared

  • From: Adrien Destugues <pulkomandy@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 4 Nov 2014 21:28:57 +0100

On Tue, Nov 04, 2014 at 03:19:54PM -0500, Augustin Cavalier wrote:
> On Tue, Nov 4, 2014 at 3:16 PM, Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> > If/when that happens, then the private namespace can be removed again,
> > until then it shouldn't be polluting the global namespace.
> >
> Well, I initially created BJson in BPrivate, but then Stephan inserted
> "using BPrivate::BJson;" at the bottom of the header. What's the difference
> (besides the binary still having the class in the private namespace)?

That is the very important difference.

Imagine some app is compiled using BToolbar today (without BPrivate).
Now it has references to the BToolbar class. It links it statically so
it runs and there is no problem.

We continue tweaking BToolbar and chanfging it a bit in ways that break
binary compatibility. The app isn't affected because it still links its
own version and doesn't see the new one in libshared (which is static
precisely to allow this)

But someday we move BToolbar to libbe. The app links against that, so it
is now confused because there are two different BToolbar classes around.

To avoid this, we put everything in libshared into the BPrivate
namespace. We remove that at the same time as we move things into libbe.
This makes sure old apps compiled against libshared don't hit a conflict
with the final version of the class published in libbe.

Finally, the "using namespace" makes it possible to recompile the app to
use the final version of the class with no changes to its sourcecode.


Other related posts: