"John Reimer" <brk_6502@NOSP_AM.yahoo.com> wrote in message news:cgjpu1$2u4u$1@digitaldaemon.com...
> Yes, that does describe the issue quite succintly.  The non-overriden read from the base class is hidden by the import statement.  It's funny I could never work up an example that showed this.  Good to know!

Right.

And as was pointed out in the past, A D programmer would be expected to 'alias' the base-class method into the current scope so that it gets picked up for the argument-matching phase ... because it's "not quite visible enough" as a superclass method.

Apparently, this path is that of the enlightened and the chosen-few.

"Regan Heath" <regan@netwin.co.nz> wrote ...
> Why [sic] is why Walter discourages import inside a class.

Well; you forget that he once encouraged them. That aside, if Walter believes that inner-imports cause name-resolution problems then perhaps he should fix it? Suggestions:

a) change the resolution rules with respect to inner imports.

b) change the method-name resolution rules. There's so many ways in which that is broken, or special-case'd. AJ's example with opCmp() would have been truly hilarious were the consequences not so sad.

c) make inner imports illegal.

d) leave everything just as it is.  Q: how does one do an emoticon for the "bird" ?

John Reimer wrote:
> ... 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:

I must be half asleep... I meant "class symbol list."

> class C {
> import std.random;
> void func1() {}
> void func2() {}
> void func3() {}
> }
> 
> void main() {
>   C c = new C;
>   uint = c.rand();    // calls std.rand()
> }
> 

and here the line:

uint = c.rand();  // calls std.rand()

should have been:

uint i = c.rand();  // calls std.rand)

Just had to correct these.  I couldn't stand reading my mistakes. :-P

Ant schrieb:
> 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.

It is a better documented alias. Besides, it would hide the symbols from the current scope. So what's wrong?

What do you have against alias anyway? (not that the D scoping difficulties would not exist, but just saying "i'm against alias" is a plain stupid position)

BTW, this would also make sense:

import std.c.stdio, std.c.stdlib as stdc;

and all modules imported with this statement would be in one namespace stdc, which makes sense when they are related. The opposite, namely that only the last one would get namespaced, would only be confusing. Besides, this allows you to save a few rows of alias statements.

-eye

Ilya Minkov schrieb:
> import std.c.stdio, std.c.stdlib as stdc;

Alternative evil wordy syntax could be:

alias private import std.c.stdio, std.c.stdlib; stdc;


Something ugly that already works:

--- 8< ---
struct cbase{
	import std.c.stdlib, std.c.stdio;
}

int main(){
	cbase.printf("%d is a nice number", cbase.rand());
	return 0;
}
--- >8 ---

-eye

On Wed, 25 Aug 2004 22:31:36 -0700, antiAlias <fu@bar.com> wrote:

> "Regan Heath" <regan@netwin.co.nz> wrote ...
>> Why [sic] is why Walter discourages import inside a class.
>
> Well; you forget that he once encouraged them.

Yes.. I did. I suspect it was more a case of the first soln that came to mind, which appeared to work at the time.

> That aside, if Walter
> believes that inner-imports cause name-resolution problems then perhaps he
> should fix it? Suggestions:
>
> a) change the resolution rules with respect to inner imports.

I think any special-case stuff should be avoided where possible.. I'm not saying we don't consider adding a special-case but the benefit aquired needs to be quite decent.

> b) change the method-name resolution rules. There's so many ways in which
> that is broken, or special-case'd. AJ's example with opCmp() would have been truly hilarious were the consequences not so sad.

I say, collate these examples, and the ones against changing (the bug caused by the change you want mentioned in the other thread) allow anyone to submit to the list, then present the list to Walter.

Only by weight of evidence will you change his mind, I suspect.

> c) make inner imports illegal.

This is the most likely course, given everything I know and have assumed about this topic.

> d) leave everything just as it is.  Q: how does one do an emoticon for the "bird" ?

No idea.. how bout:

            /´¯/)
          ,/¯  /
         /    /
    /´¯/'   '/´¯¯`·¸
 /'/   /    /       /¨¯\
('(   ´   ´     ¯~/'   ')
 \                 '   /
  ''   \           _ ·´
    \              (
      \             \

<g>

Regan

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

"Ant" <Ant_member@pathlink.com> wrote in message news:cgi9sa$2715$1@digitaldaemon.com...
> 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?

They are supported. What happens, though, is confusion about how symbol lookup rules work with modules, for example, the names in an imported module will then override names in the base class.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:cgil87$2cn3$1@digitaldaemon.com...
>
>
> > 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.

That's true. But the import will be searched before the base class, and before the other symbols outside the class. This is usually not what was intended.

"Regan Heath" <regan@netwin.co.nz> wrote
> > d) leave everything just as it is.  Q: how does one do an emoticon for the "bird" ?
>
> No idea.. how bout:
>
>              /´¯/)
>            ,/¯  /
>           /    /
>      /´¯/'   '/´¯¯`·¸
>   /'/   /    /       /¨¯\
> ('(   ´   ´     ¯~/'   ')
>   \                 '   /
>    ''   \           _ ·´
>      \              (
>        \             \
>
> <g>

Hey! Nice work, man :-)

"Walter" <newshound@digitalmars.com> wrote
>
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:cgil87$2cn3$1@digitaldaemon.com...
> >
> >
> > > 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.
>
> That's true. But the import will be searched before the base class, and before the other symbols outside the class. This is usually not what was intended.

Does that "usually not what was intended" aspect not ring any alarm bells?