public import and bugs it causes
schveiguy at yahoo.com
Fri May 14 19:40:07 PDT 2010
On Fri, 14 May 2010 21:19:38 -0400, Alex Makhotin <alex at bitprox.com> wrote:
> Walter Bright wrote:
>> You can import only those names you wish. See static imports, renamed
>> imports and selective imports in
> OK, 'static import' combination seems to force use of fully qualified
> name. Requires a lot of typing of the fully names for imported classes.
> A lot of typing only for the sake of one global variable.
> The renamed import also requires countless typing using the renamed
> The specific imports require me to select what to import(again all the
> work on me, not the tool I use). Oh no. Every time I desire to use some
> member of the import I type 'import module : memberiwant'.
You are blowing this way out of proportion. I don't ever remember having
to rename or statically import std.stdio. D's default is to import all
names into your local namespace, that is good enough 99% of the time.
Sometimes you need to rename things, or force static resolution. In those
cases, the tools are there.
But you want to require globals to be referred to by fully qualified
names? How does it sound that you have to write std.stdio.writeln every
time you want to write something?
The problem as I see it is that std.compiler has a poorly named global
variable. You can rename that variable when importing, lessening your
pain, or you can statically import it, making your job a little more
difficult, but more precise. Or you can get the author to change it.
There are several options, and all of them seem way way more attractive
than ruining the syntax for the rest of the well-named module globals.
'name' just is a single bad global name, it does not make all globals
> As far as I know the C# hasn't such complications, why should D?
C# sucks when importing conflicting names. I've dealt with it, and you
simply have to refer to the fully qualified name to be unambiguous. With
D, I can rename the less used one at import time to only have to rewrite
some of them. This does not ruin the experience for anyone else who uses
only one of the modules. Note that D refuses to compile ambiguous
symbols, so the problem is not that it blindly chooses one.
You also have to refer to all functions and symbols inside a class, if
it's not the class you are writing. Without the IDE, this would be
torture. A good example is writing output -- Console.WriteLine(x). I'll
take writeln(x) any day over that.
C# is not the model to follow.
More information about the Digitalmars-d