(We have had some suggestions to change the import declarations.
many inspired from other languages.)

In D we are able to declare imports at the module top level and on the class body.

Walter says he doesn't recomend the latter. Why?

I once said:

>> work around:
>>
>> move the import to inside the class body.

and Walter responded:

>
>I strongly recommend against doing that. There must be a better solution than that.

so I'm saying:

Why shouldn't it be supported, unless if difficult to maintain?
On OO coding I'm going to use the imported symbols only on inside the body of
the class so it makes perfect sence that the import is declared
inside the class body. People just aren't use to it. I don't see this
has an hack to avoid other problems but as the logic scope to insert
the import decalration.
Java doesn't need this because (almost) nothing else goes outside class bodies.

when declared inside the class body the simbols should
be available only to subclasses (unless they are private...).

So who's with me to try to convince Walter to continue to support import declarations inside the class body?

Ant

Ant wrote:

> Why shouldn't it be supported, unless if difficult to maintain?
> On OO coding I'm going to use the imported symbols only on inside the body of
> the class so it makes perfect sence that the import is declared
> inside the class body. People just aren't use to it. I don't see this
> has an hack to avoid other problems but as the logic scope to insert
> the import decalration.
> Java doesn't need this because (almost) nothing else goes outside class bodies.
> 
> when declared inside the class body the simbols should
> be available only to subclasses (unless they are private...).
> 
> So who's with me to try to convince Walter to continue to support import declarations inside the class body?

I think Walter was talking about using class-level imports to resolve circular reference issues.  I agree with him: it's a terrible, terrible hack around the problem and it introduces all manner of problems later on down the line.

The problem may be that the import statement does two distinct, unrelated things instead of just one.

First, import tells DMD to scan some source file, in some directory. The symbols in this file are made available to the source program.

Second, import pulls all of those symbols into the current scope.

The second of these behaviours sounds suspiciously like a mass-alias to me.  Such a thing would be useful in its own right, and it would be a good thing to separate the two concepts into distinct statements. ie

    import std.string; // std.string is added to the known scopes
    alias std.string.*;// alias all of std.string into the present scope

This makes it clearer that you /want/ all of those symbols to be part of the class definition.  It also helps keep the global namespace cleaner by making it much more realistic to say that the only things in a module's scope are declared there explicitly. (unless you use alias x.*;) Doing this presently is a bit of a chore:

    private struct std { struct string {
        import std.string;
    }

 -- andy

> First, import tells DMD to scan some source file, in some directory. The symbols in this file are made available to the source program.
>
> Second, import pulls all of those symbols into the current scope.

It does? I thought a symbol in an imported module will only be searched for if DMD can't find the symbol in the current scope. So import doesn't bring symbols into the current scope- it just says where to look if the symbol isn't in the current scope. Alias defines a new symbol in the current scope.

> The second of these behaviours sounds suspiciously like a mass-alias to me.  Such a thing would be useful in its own right, and it would be a good thing to separate the two concepts into distinct statements. ie
>
>      import std.string; // std.string is added to the known scopes
>      alias std.string.*;// alias all of std.string into the present scope
>
> This makes it clearer that you /want/ all of those symbols to be part of the class definition.  It also helps keep the global namespace cleaner by making it much more realistic to say that the only things in a module's scope are declared there explicitly. (unless you use alias x.*;) Doing this presently is a bit of a chore:
>
>      private struct std { struct string {
>          import std.string;
>      }
>
>   -- andy

In article <cgil87$2cn3$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>
>> First, import tells DMD to scan some source file, in some directory. The symbols in this file are made available to the source program.
>>
>> Second, import pulls all of those symbols into the current scope.
>
>It does? I thought a symbol in an imported module will only be searched for if DMD can't find the symbol in the current scope.

that changed on 0.91 (the start of the stall for my projects)

> So import doesn't bring
>symbols into the current scope- it just says where to look if the symbol isn't in the current scope.

No, the imported will overide the locals!

Ant

In article <cgid2l$28fg$1@digitaldaemon.com>, Andy Friesen says...
>
>The second of these behaviours sounds suspiciously like a mass-alias to me.  Such a thing would be useful in its own right, and it would be a good thing to separate the two concepts into distinct statements. ie
>
>     import std.string; // std.string is added to the known scopes
>     alias std.string.*;// alias all of std.string into the present scope

(alias is evil)
maybe that could be done on the import:

import std.string; // std.string is added to the known scopes import std.string.*;// all of std.string into the present scope

(not to be mistaken for import std.*;)

Ant

In article <cgimgj$2dap$1@digitaldaemon.com>, Ant says...
>
>In article <cgil87$2cn3$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>> First, import tells DMD to scan some source file, in some directory. The symbols in this file are made available to the source program.
>>>
>>> Second, import pulls all of those symbols into the current scope.
>>
>>It does? I thought a symbol in an imported module will only be searched for if DMD can't find the symbol in the current scope.
>
>that changed on 0.91 (the start of the stall for my projects)
>
>> So import doesn't bring
>>symbols into the current scope- it just says where to look if the symbol isn't in the current scope.
>
>No, the imported will overide the locals!

Really?  That sounds broken to me.


Sean

"Ant" <Ant_member@pathlink.com> wrote in message news:cgimgj$2dap$1@digitaldaemon.com...
> In article <cgil87$2cn3$1@digitaldaemon.com>, Ben Hinkle says...
> >
> >
> >
> >> First, import tells DMD to scan some source file, in some directory. The symbols in this file are made available to the source program.
> >>
> >> Second, import pulls all of those symbols into the current scope.
> >
> >It does? I thought a symbol in an imported module will only be searched
for
> >if DMD can't find the symbol in the current scope.
>
> that changed on 0.91 (the start of the stall for my projects)

Here's a little test case with two files, mod1.d and mod2.d:

file mod1.d:
module mod1;
void foo(int x){};

file mod2.d:
module mod2;
class A{
  import mod1;
  void foo(){};
  void bar(){ foo(); }
}
void main(){};

This compiles fine since foo inside A resolves to A.foo. If bar is changed
to
  void bar(){foo(100);}
then it no longer compiles because mod1.foo is not part of the overload
resolution for foo inside A. So I'm a bit confused about the statement that
"import pulls all the symbols into the current scope". I'm not sure what
"pulls" means. You give a small example of what is going wrong in your code?

> > So import doesn't bring
> >symbols into the current scope- it just says where to look if the symbol isn't in the current scope.
>
> No, the imported will overide the locals!

what do you mean by "override"? Do you mean overload (as in function overloading)? Overload resolution happens after the name resolution.

Ant schrieb:
> (alias is evil)

It might also impose a parsing problem - 1 vs 2 arguments depending on a type of the alias.

> maybe that could be done on the import:
> 
> import std.string; // std.string is added to the known scopes
> import std.string.*;// all of std.string into the present scope
> 
> (not to be mistaken for import std.*;)

yup, makes sense to me. But i would think that usually it's more comfy to replace the long scope name by a short one:

import std.string as sstr;

or even multiple such statements to put many imports into the same scope. perhaps this could also be done with a scope alias afterwards, but "as" seems more descriptive to me.

this may be stupid example but with longer hierarchies it would really matter.

In article <cgiqb8$2f8e$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>Here's a little test case with two files, mod1.d and mod2.d:
>
>file mod1.d:
>module mod1;
>void foo(int x){};
>
>file mod2.d:
>module mod2;
>class A{
>  import mod1;
>  void foo(){};
>  void bar(){ foo(); }
>}
>void main(){};

I don't have D here.
try print out something different on A.foo()
and a new function void foo() in module mod1.
I'm saying that
the method called from A.bar() will be the one from mod1.

>
>This compiles fine since foo inside A resolves to A.foo.

not if there is a method void foo() on mod1.

If bar is changed
>to
>  void bar(){foo(100);}
>then it no longer compiles because mod1.foo is not part of the overload resolution for foo inside A.

this is a surprise to me! it makes import useless (????)

> So I'm a bit confused about the statement that
>"import pulls all the symbols into the current scope". I'm not sure what "pulls" means. You give a small example of what is going wrong in your code?
>
>> > So import doesn't bring
>> >symbols into the current scope- it just says where to look if the symbol isn't in the current scope.
>>
>> No, the imported will overide the locals!
>
>what do you mean by "override"?

I mean hide, kill, make disapear...
in your example you overload foo, I thought that was OK but you say
it doesn't compile(?)

Ant

In article <cgiqie$2fa3$1@digitaldaemon.com>, Ilya Minkov says...
>
>Ant schrieb:
>> 
>> import std.string; // std.string is added to the known scopes import std.string.*;// all of std.string into the present scope
>> 
>> (not to be mistaken for import std.*;)
>
>yup, makes sense to me. But i would think that usually it's more comfy to replace the long scope name by a short one:
>
>import std.string as sstr;
>

I suggested this a long time ago.
I added that the "std.string" should no longer be valid on this scope.
(I think I was inspired by Oberon)

but I'm not sure anymore, it's a diskised alias.

Ant