Optional module names export list

spir denis.spir at gmail.com
Sat Feb 19 16:48:00 PST 2011


On 02/20/2011 12:46 AM, bearophile wrote:
> In a Python module if you define a name with a starting underscore, that name will be private to that module, and it will not be imported if a command "from module_name import *" is used:
>
> class Name1: pass
> def name2(): pass
> _private_name3 = 3
> name4 = 4
>
> In Python there is another optional way to specify the list of names imported: if a module (or package __init__.py code) defines a list named __all__, it is taken to be the list of module names that should be imported when a "from package import *" command is used.
>
> So from this module you will not import name2 and _private_name3:
>
> class Name1: pass
> def name2(): pass
> _private_name3 = 3
> name4 = 4
> __all__ = ["Name1", "name4"]
>
>
> In Haskell there is a similar way to list the names to export from a module, this module exports the name1, Name2, name3, ... names only:
>
> module Foo(name1, Name2, name3, ...) where
> -- module contents here
>
>
> Several other languages have a similar feature.
>
> In a D module you add a "private" beside each global name you don't want to export from a module. (Maybe you are also allowed to use a "private:" at the module top, and then add a "public" to each of the names you want to export, but this doesn't look so safe, because you may miss a "public:" lost in the middle of the module code).
>
> For a safer management of exported names, in D it may be useful an optional way to explicitly list (probably at the top of the module) the module names exported. A possible syntax is similar to the Haskell one:
>
> module foo(name1, name2, Name3, ...);
>
> Bye,
> bearophile

I would love such a feature. In fact, I think
	import foo;
should launch
	Error: module 'foo' does not define exported symbols.
if, actually, 'foo' does not...

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



More information about the Digitalmars-d mailing list