Export ?

[Johannes Pfau]

Am Wed, 11 Apr 2012 20:27:31 +0200
schrieb Paulo Pinto <pjmlp at progtools.org>:

> Am 11.04.2012 19:03, schrieb Johannes Pfau:
> > Am Wed, 11 Apr 2012 11:56:00 +0200
> > schrieb deadalnix<deadalnix at gmail.com>:
> >>
> >> It isn't a misfeature. The link explain why it is interesting :
> >>    - It improves load time of DSO.
> >>    - Allow more optimizations.
> >>    - Reduce DSO size by 5% to 20% for C++. Considering how long
> >> mangling are in D, probably more for us.
> >>    - Reduce name collision (this one poorly apply to D, because the
> >> module system handle that quite nicely).
> >>
> >> Additionally, it allow automatic finalization for non exported
> >> methods in D.
> >>
> >
> > This explains why symbol visibility is useful. But do we really need
> > 'export'? Are there cases where public = export, private/package =
> > 'not exported' wouldn't work?
> >
> > When do you actually need 'not-exported' and public? And would
> > export private/export package be valid?
> >
> 
> 
> For example, a so/dll might be composed of several D packages. In
> those packages you want the public symbols to be visible between
> packages, but not visible to the applications that link to your
> so/dll library.
> 

OK, I understand. I still can't think of a concrete example where I
would want that behavior, but I'll just trust you all that it's useful.

> This is why many languages make a distinction between modules and 
> packages. Usually a module is composed of several packages.
> 
> These type of modularity might seem complex, but actually is a good
> way to modularize applications.