Am Wed, 11 Apr 2012 20:27:31 +0200 schrieb Paulo Pinto <[email protected]>:
> Am 11.04.2012 19:03, schrieb Johannes Pfau: > > Am Wed, 11 Apr 2012 11:56:00 +0200 > > schrieb deadalnix<[email protected]>: > >> > >> 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.
