Clay language

[spir]

On Wed, 29 Dec 2010 19:24:12 +0100
Andrej Mitrovic <andrej.mitrovich at gmail.com> 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