Export ?

[Paulo Pinto]

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.

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.