Den 11-06-2011 03:26, David Nadlinger skrev:
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).
+1
