On Wed, 29 Dec 2010 19:24:12 +0100
Andrej Mitrovic <[email protected]> wrote:
> But I really don't see the benefit of changing the semantics of
> import. You won't get shot in the foot since D offers good protection
> from function hijacking.
Yes, I'm aware of this. But this (great) feature is not related to the
discussion, I guess.
> But even if you did change the semantics of import to a static import,
> you still wouldn't fix the *programmers* themselves. Everyone will
> simply start using /import module.*/, or /import module.all/ instead
> of using the safe default /import module/ which would be a static
> import. No defined default or convention in the community can force
> programmers to code in one way.
>
> And if you doubt that, just take a look at all the Python code that's
> out there. A ton of programmers still use the star syntax to import
> every symbol into the current scope, even though its frowned upon by
> the Python community (and afaik you can't use it anymore in Python 3).
> But D has counter-measures which prevent hijacking, and hence it's
> pretty safe to simply import the whole module without worrying too
> much.
We certainly don't read code by the same programmers ;-) I have never seen
"from x import *" except in newcomer code and case like evoked in a previous
post, namely parsing: a parser-definition module using eg "from pyparsing
import *".
A counter measure is to define what is to be exported. (A very nice feature of
Lua: th module's return {whatever you want to export}). Similarly in python you
get __all__ (some proposed to allow import * only id the module defines
__all__, sensible indeed).
In D you have to define everything _else_ in the module private: not only it's
not the default, it's imo reversing the logic.
[Now, i'll stop arguing ;-)]
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
