Ivan Senji wrote:
> Walter Bright wrote:
>> Ivan Senji wrote:
>>> How does this sound in the documentation:
>>> "A module level function that is declared private can not be used in
>>> another module unless there is another public function with the same
>>> name."
>>> <- This is just crazy(or does it justsound crazy to me), IMO private
>>> "void foo(long x);" in the above example should not be included in the
>>> overload resolution.
>> Consider the following C++ code:
>>
>> struct S
>> {
>>     public void foo(long);
>>     private void foo(int);
>> };
>> struct T
>> {
>>     public void foo(long);
>> };
>>
>> ....
>>
>> S s;
>> s.foo(1);    // error, foo(int) is private
>> T t;
>> t.foo(1);    // ok
>>
>> Note that it sees S::foo(int) and it participates in overload resolution even though it is private. In other words, accessibility is checked after lookup and after overload resolution.
> 
> I really do understand the way C++ does things, but are you sure this is
> the best/smartest way? We all know that D is not C++(a Good Thing).
> I think that to most people private will mean that whatever is declared
> private is invisible (in another module).
> 
> More C++ code (methods a little bit more different to avoid thinking about implicit type conversions):
> 
> struct S
> {
>     public: void foo(int a){}
>     private: void foo(string b){}
> };
> 
> S s;
> s.foo(1);
> s.foo("Bla"); <- atleast in C++(unlike D) this isn't allowed, i got a
> message:

I should point out that I know that this is a bug in the current D implementation, but it is a bug that would not be possible if the compiler just didn't see/ignored private stuff from other modules.

By private stuff I also mean private classes.

Derek Parnell wrote:
> I'm sorry Walter but I don't give newt's fart about C++. If I wanted to code under the rules of C++, I'd use C++. You have changed (improved) many of the C++ rules in D, so why not get this one right too?

I agree that D exists to fix broken rules in C++, but we need to understand the rationale for why they are the way they are in C++, else we run the risk of making a severe error. I don't recall why the access rules are the way they are in C++, but I do know they weren't don't that way for backwards compatibility.

In article <e8nq1e$16r$1@digitaldaemon.com>, Walter Bright says...
>
>Walter Bright wrote:
>>>> What can also be done is extend the import declaration to allow the .'s to continue so that specific symbols can be imported.
>>>
>>> Now that would be great. I believe selective-importing (as an option) would be a boon in a number of ways ~ and would resolve this issue quite elegantly.
>> 
>> I like this one better, too.
>
>There's another way - have a different kind of import declaration, say, precede it with static:
>
>	static import foo;
>
>which will make the symbols in foo available, but only if they are explicitly qualified. Then one could access bar in foo by either:
>
>	foo.bar();
>
>or:
>
>	alias foo.bar bar;
>	bar();
>
>but not:
>
>	bar();	// error, undefined symbol
>
>The advantage of this is it is a bit more flexible and more consistent with the way the rest of D lookups work.

Er, that really doesn't work at all. Please ignore what I said a few minutes ago regarding this option (I really should get some sleep instead).

The problem here is that, for the proposed static imports, everything must be fully-qualified with the /original import name/, and that's just plain awful for long import names. The "import as" allows one to give it a nice short name instead.

And, I still think the selective-import is the superior solution anyway.

(I'd delete my earlier reply, but TBird is doing really wierd things with messages right now, and is basically hiding all my own posts)

Walter Bright wrote:

> There's another way - have a different kind of import declaration, say, precede it with static:
> 
> 	static import foo;
> 
> which will make the symbols in foo available, but only if they are explicitly qualified. Then one could access bar in foo by either:
> 
> 	foo.bar();
> 
> or:
> 
> 	alias foo.bar bar;
> 	bar();
> 
> but not:
> 
> 	bar();	// error, undefined symbol
> 
> The advantage of this is it is a bit more flexible and more consistent with the way the rest of D lookups work.

Yes, that's what I was talking about in http://www.digitalmars.com/d/archives/digitalmars/D/39348.html

Finally got a feedback from Walter :-).

Looking forward to see this implemented.

-- 
AKhropov

Andrei Khropov wrote:
> Looking forward to see this implemented.
> 
I have wanted this to. Please implement it Walter.

Walter Bright wrote:

> There's another way - have a different kind of import declaration, say, precede it with static:
> 
> 	static import foo;
> 
> which will make the symbols in foo available, but only if they are explicitly qualified. Then one could access bar in foo by either:
> 
> 	foo.bar();
> 
> or:
> 
> 	alias foo.bar bar;
> 	bar();
> 
> but not:
> 
> 	bar();	// error, undefined symbol
> 
> The advantage of this is it is a bit more flexible and more consistent with the way the rest of D lookups work.

That's what I was talking about in http://www.digitalmars.com/d/archives/digitalmars/D/39348.html

Finally got a feedback from Walter :-)

Looking forward to see this in future releases.

"as" would be nice too but it's just syntactic sugar for fqn import + alias.

-- 
AKhropov

Andrei Khropov wrote:

> Walter Bright wrote:
> 
> > There's another way - have a different kind of import declaration, say, precede it with static:
> > 
> > 	static import foo;
> > 
> > which will make the symbols in foo available, but only if they are explicitly qualified. Then one could access bar in foo by either:
> > 
> > 	foo.bar();
> > 
> > or:
> > 
> > 	alias foo.bar bar;
> > 	bar();
> > 
> > but not:
> > 
> > 	bar();	// error, undefined symbol
> > 
> > The advantage of this is it is a bit more flexible and more consistent with the way the rest of D lookups work.
> 
> Yes, that's what I was talking about in http://www.digitalmars.com/d/archives/digitalmars/D/39348.html
> 
> Finally got a feedback from Walter :-).
> 
> Looking forward to see this implemented.

Hmm, this was an answer to the http://www.digitalmars.com/d/archives/digitalmars/D/39784.html

Why is it here? Perhaps some problems with my news client :confused: .


-- 

Andrei Khropov wrote:

> Walter Bright wrote:
> 
> > There's another way - have a different kind of import declaration, say, precede it with static:
> > 
> > 	static import foo;
> > 
> > which will make the symbols in foo available, but only if they are explicitly qualified. Then one could access bar in foo by either:
> > 
> > 	foo.bar();
> > 
> > or:
> > 
> > 	alias foo.bar bar;
> > 	bar();
> > 
> > but not:
> > 
> > 	bar();	// error, undefined symbol
> > 
> > The advantage of this is it is a bit more flexible and more consistent with the way the rest of D lookups work.
> 
> That's what I was talking about in http://www.digitalmars.com/d/archives/digitalmars/D/39348.html
> 
> Finally got a feedback from Walter :-)
> 
> Looking forward to see this in future releases.
> 
> "as" would be nice too but it's just syntactic sugar for fqn import + alias.

I'm sorry, this was an answer to the http://www.digitalmars.com/d/archives/digitalmars/D/39784.html .

My damn news client posts it everywhere except the place place it's supposed to be.

-- 

Walter Bright wrote:
> kris wrote:
> 
>> So, in D, what does private actually mean? The verbose version if you wouldn't mind, with all known corner-cases noted?
>>
>> I think the full explanation would help a lot, since it's often easier to remember the things one should not do, rather than those one should.
> 
> 
> It means the same thing as in C++. It should give an error if you try to access a private member in another module - but the symbol is still found.

Aside from the 'its like C++' argument, why make it visible at all?

Making these things spill over is an unnecessary chore for development, imo.

When I tell the man at Pikes Nursery I want some grass, its a lot different than when I say it to the undercover cop on the street corner.

-DavidM

Walter Bright escribió:
> kris wrote:
>> Walter Bright wrote:
>>
>>> What can also be done is extend the import declaration to allow the .'s to continue so that specific symbols can be imported.
>>
>> Now that would be great. I believe selective-importing (as an option) would be a boon in a number of ways ~ and would resolve this issue quite elegantly.
> 
> I like this one better, too.
> 
> 

I like it too, but I have a question: how far would it go? Would we be able to do this:

//----------

module a;

class Foo
{
	enum Bar { ... }
	
	struct Baz
	{
		const something = ...;
	}
}

//----------

module b;

import a.Foo.Bar;
import a.Foo.Baz.something;

//----------

Or just module members?

-- 
Carlos Santander Bernal