On 6/11/11 3:21 AM, bearophile wrote:
Andrei:
This module won't compile in today's D, but not for a matter of
principles; it's just a random limitation of the language. (It does work
if you import from within a class or struct.) You can insert most
declarations in a scope, so the ones you can't insert are just awkward
exceptions, unless there's a good reason to actively disable them. Any
code should work if you just wrap another scope around it.
Walter and I call the above a "turtle feature", in allusion to the
"turtles all the way down" meme. Walter wants to fix this, and similar
limitations that act "unturtly". Imports inside a scope won't be visible
outside that scope, and importing the same module from several different
functions will come at no cost in compilation time.
You are allowed to import modules inside functions in Python too (there is a
just a minor restriction), but I have never asked for this feature in D because
this feature has a cost too. Putting all imports at the top of the module is
more tidy, it allows the person that reads the code to find all the used
imports very quickly. If they are spread in the module they become less easy to
find, you need to use your editor/IDE to search for them.
Bye,
bearophile
At least allowing imports in unittests would be nice though – I
frequently find myself writing »version (unittest) {}« blocks before the
actual unit tests just to import some modules not needed during regular
builds (yeah, I suppose I'm somewhat pedantic about that).
David
