Am 11.04.2012 19:03, schrieb Johannes Pfau:
Am Wed, 11 Apr 2012 11:56:00 +0200
schrieb deadalnix<deadal...@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.
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.
