"Ant" <Ant_member@pathlink.com> wrote in message news:cgirvn$2g0t$1@digitaldaemon.com...
> 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.

I tried again with
file mod1.d:
module mod1;
void foo(){printf("hello\n");};

file mod2.d:
module mod2;
class A {
  import mod1;
  void foo(){printf("in A\n");};
  void bar(){ foo(); }
}
void main(){
A a = new A;
a.bar();
};

and it prints "in A" as I would expect. So it looks like the right one is found.

> >
> >This compiles fine since foo inside A resolves to A.foo.
>
> not if there is a method void foo() on mod1.

Hmm. I could compile ok with foo() instead of foo(int x).

> 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 (????)

why useless? import is for name resolution and not overload resolution.

> > 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

Without code it's hard to get into the details - words tend to be imprecise and this name/overloading resolution stuff tends to get confusing without concrete examples. I afraid I still don't get the problem.

In article <cgitmo$2gpm$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Ant" <Ant_member@pathlink.com> wrote in message news:cgirvn$2g0t$1@digitaldaemon.com...
>> In article <cgiqb8$2f8e$1@digitaldaemon.com>, Ben Hinkle says...
>
>I tried again with
[...]

ok!, the new example you reported sounds good.
as you expected, and I, and every body else expected until dmd 0.91.

all other considerations I made have no base now.

>I afraid I still don't get the problem.

You just prove I have no problem.
I'll try the modified example with 0.98 (the one I'm using)
and if I still have it with 0.91 (just to save my face...)

Ant

In article <cgitmo$2gpm$1@digitaldaemon.com>, Ben Hinkle says...
>
>

just for reference here is when I first panicked: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/323

Ant

Ant wrote:
> 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)

Why?

> 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

It's still an alias, whether you use the 'alias' keyword or not.

 -- andy

Ben Hinkle wrote:
> "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);}

This has been discussed before.  In some obscure situation (specifically a past mango internal issue), importing mod1.d within the class scope would have caused A.foo() to be hidden completely.  Any calls to A.foo() with or without an argument would call the mod1.d foo().  It appears that nobody could actually replicate the problem that mango was experiencing.  Small examples such as yours always seem to work as expected.

> 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?
> 

When it comes to overloading, I believe you are correct.  Imported modules are not included in the overload resolution.  What he meant about class scope import "pulling" names into the module, I beleive, is this:  all method names imported into class scope seem to become part of the classes symbol; by this I mean that all imported functions can actually be called as if they are class methods. An example:

class C {
import std.random;
void func1() {}
void func2() {}
void func3() {}
}

void main() {
  C c = new C;
  uint = c.rand();    // calls std.rand()
}

I believe this is what Andy meant by names being "pulled" into the class.  And this is why internal imports do the equivalent to a mass alias in this situation.

>>>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.
> 

No, not overload.  Like I mentioned above, some "big" projects have had issues with the import within the class causing a hiding of method names with the same name as an imported function, no matter what the method signature.  That is, using my example above, if class C also defined it's own rand() method, this method would be hidden by the local import's rand() even if the signatures were completely different.  Once again it's been hard to demonstrate in a small example what's actually happening in those projects.  The small examples always seem to work as expected.  I've kind of given up trying to figure it why it sometimes works and sometimes doesn't.  And, yes, Walter has explained the rules for name resolution several times.  This issue used to be a problem, but it may have changed with new dmd revisions.  Ant seems to be still be experiencing it, so maybe it is still lurking in the bigger projects.

- John

In article <cgj2dr$2j1i$1@digitaldaemon.com>, Andy Friesen says...
>
>Ant wrote:
>> 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)
>
>Why?

because you'll end up with more then one designation for the same entity. entropy doesn't need the programmer's help, it will grow by it self.

(but I'm afraid it's a necessary 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
>
>It's still an alias, whether you use the 'alias' keyword or not.

sure (see my other post on this thread) but at least we get rid of the token... it's not necessary here.

Ant

Ant wrote:
>>>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
>>
>>It's still an alias, whether you use the 'alias' keyword or not.
> 
> 
> sure (see my other post on this thread) but at least we get
> rid of the token... it's not necessary here.

I think it is necessary.  Something that behaves like an alias really should look like one.

"Explicit is better than implicit." -- The Zen of Python, by Tim Peters

 -- andy

On Wed, 25 Aug 2004 15:23:31 -0700, John Reimer <brk_6502@NOSP_AM.yahoo.com> wrote:

<snip>

>> 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);}
>
> This has been discussed before.  In some obscure situation (specifically a past mango internal issue), importing mod1.d within the class scope would have caused A.foo() to be hidden completely.  Any calls to A.foo() with or without an argument would call the mod1.d foo().  It appears that nobody could actually replicate the problem that mango was experiencing.  Small examples such as yours always seem to work as expected.

IIRC it was that the import was overloading a base class method, like 'pause' in threads or 'read' in a buffer class?

This small example exhibits that behaviour:
--[mod1.d]--
module mod1;

void read() {
  printf("read\n");
}

--[mod2.d]--
module mod2;

class Base {
  void read() {
    printf("Base::read\n");
  }
}

class Child : Base {
  import mod1;

  void foo() {
    read();
  }
}

void main()
{
  Child c = new Child();
  c.foo();
}

c.foo calls 'read' which calls mod1.read, NOT, mod2.Base.read.

<snip>

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Thu, 26 Aug 2004 11:49:49 +1200, Regan Heath wrote:

> 
> This small example exhibits that behaviour:

That shows the same as my original example.
Walter confirmed this is the desired behaviour.
That's when I decided that D can't be used
with anything else but strict 00. Which suit me fine!

Ant

On Wed, 25 Aug 2004 22:05:58 -0400, Ant <duitoolkit@yahoo.ca> wrote:
> On Thu, 26 Aug 2004 11:49:49 +1200, Regan Heath wrote:
>
>>
>> This small example exhibits that behaviour:
>
> That shows the same as my original example.
> Walter confirmed this is the desired behaviour.

Can Walter please re-confim that for me...
Walter, Ant is saying that this code:

<ben's example>
I tried again with
file mod1.d:
module mod1;
void foo(){printf("hello\n");};

file mod2.d:
module mod2;
class A {
  import mod1;
  void foo(){printf("in A\n");};
  void bar(){ foo(); }
}
void main(){
A a = new A;
a.bar();
};

and it prints "in A" as I would expect. So it looks like the right one is
found.
</ben's example>

and this code

<my example>
--[mod1.d]--
module mod1;

void read() {
  printf("read\n");
}

--[mod2.d]--
module mod2;

class Base {
  void read() {
    printf("Base::read\n");
  }
}

class Child : Base {
  import mod1;

  void foo() {
    read();
  }
}

void main()
{
  Child c = new Child();
  c.foo();
}

c.foo calls 'read' which calls mod1.read, NOT, mod2.Base.read.
</my example>

Exhibit the desired behaviour?

It appears it's the name resolution rules again. In my example it finds the imported symbol before it finds the base class symbol. In ben's it finds the local symbol before the imported symbol.

I believe Ant desires that the base symbol would be found before the imported symbol.

Are imports supposed to overload (correct term?) class methods? If so, why doesn't it overload in bens example?

> That's when I decided that D can't be used
> with anything else but strict 00. Which suit me fine!

I've not given up on this yet..

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/