On Sat, 08 Jul 2006 18:15:35 +1000, kris <foo@bar.com> wrote:


>>   That why I wrote http://www.users.bigpond.com/ddparnell/attr.html

> I read it several times; it didn't seem to follow the compiler behaviour, which is not any fault of the messenger.

I know it doesn't and that is exactly what I was trying to get a comment on. Is the documentation right or is the compiler right. In anycase, get the documentation right first then fix the compiler.

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> On Sat, 08 Jul 2006 13:38:13 +1000, Walter Bright <newshound@digitalmars.com> wrote:
> 
>> Derek Parnell wrote:
>>> On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright <newshound@digitalmars.com> wrote:
>>>
>>>> The alias works at any level you choose to make it. Alias can be used to 'import' any name into the current namespace, making it first class.
>>>  Even names that are declared 'private' in the imported module? Is
>>> that how you want it to work Walter? If so, why do we bother with
>>> 'private'? What's the point?
>>
>> In class scope, access control is done *after* name lookup, not before. I'm concerned about confusion by reversing the order of that for module scope.
> 
> Well don't be concerned. It is far more confusing for something declared as private to be not seen as private. I believe the natural way of thinking for people is that some that is "private" is not to be *seen* by others, and thus not accessed. So I naturally think that if the compiler notices that something is "private" it just pretends that it didn't see it and acts as if it doesn't exist.

Exactly, the fact that something can or cannot be accessed should be related to its visibility. (And private to me sounds like invisible).

> 
> I am totally convinced that the current thinking is unnatural. That the compile sees something therefore ignores the wishes of the author.

Indeed!

On Sat, 08 Jul 2006 13:36:49 +1000, Walter Bright <newshound@digitalmars.com> wrote:


> But the suggestions involve changing the importer code, too. I'm not seeing the advantage of that over fully qualifying the references or using an alias, both of which will ensure that no future imports will cause name collisions.

I tend to agree with Walter on this one. The only thing that might be needed in a post 1.0 edition of D is some syntax help to make the job of tedious alias coding a lot easier.

> What can be done is something like add a warning whenever a name is found using the second-class import lookup, rather than using an alias or a fully qualified lookup. Then, you'll be able to easily purge your code of any such, and be confident that adding other modules will not break your existing code.

Not a bad idea at all.

> What can also be done is extend the import declaration to allow the .'s to continue so that specific symbols can be imported.

An excellent idea because it does the job and follows the consistent look of D. Makes my job in Build a bit harder though ;-)

-- 
Derek Parnell
Melbourne, Australia

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.

Derek Parnell wrote:
> On Sat, 08 Jul 2006 18:07:34 +1000, Ivan Senji  <ivan.senji_REMOVE_@_THIS__gmail.com> wrote:
> 
>> Derek Parnell wrote:
>>
>>> On Sat, 08 Jul 2006 14:47:34 +1000, Walter Bright
>>> <newshound@digitalmars.com> wrote:
>>>
>>>> Brad Roberts wrote:
>>>
>>>
>>>>>  How much begging would it take to try for a release or two having
>>>>> private symbols invisible to the importer?  It's really much more
>>>>> intuitive, imho.  I haven't looked at this part of the front end
>>>>> code, but if it's easy, feel free to make it controllable via a
>>>>> compiler option just for the experiment's time frame.
>>>>
>>>>
>>>> The problems happen when one has:
>>>>
>>>> void foo(int x);
>>>> private void foo(long x);
>>>>
>>>> So the first foo is found, then overload rules apply, and the second
>>>> foo is selected.
>>>
>>>
>>> No.... what would happen if something outside the module called
>>> foo(long) is that foo(int) would be called due to implicit casts and
>>> that the module's foo(long) is invisible to the caller. It wouldn't be
>>> called because the caller should not be able to see it.
>>>
>>
>> Yes, but:
>> If the functions were actually:
>>
>> void foo(int x);
>> private void foo(char[] x);
>>
>> and in another module foo("bar"); the right function would be called
>> even though it is private.
>> The problem: the caller does see it if there is another function with
>> the same name.
> 
> 
> I agree that that is the problem. Calling foo("bar") should fail as that  is private to the module and the caller should not be able to access it  *BECAUSE* it is private even though the compiler can actually 'see' it.
> 

FWIW, you've got my support to make private actually mean Private (with a capital P). Anything else is surely counter-intuitive; certainly seems to ignore any "principal of least surprise"

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.

On Sat, 08 Jul 2006 18:23:09 +1000, Walter Bright <newshound@digitalmars.com> 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.
>
> 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.

Nice. But only if foo.bar is not private. If its private the caller should not be able to call it.

-- 
Derek Parnell
Melbourne, Australia

On Sat, 08 Jul 2006 18:26:46 +1000, Walter Bright <newshound@digitalmars.com> 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  lookup and after overload resolution.


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?

Given the example above, I'd prefer that the overload resolution rules would not even consider S.foo(int) because its private (from the caller's perspective) so it would only see the public function and resolve overloads based on what it is allowed to access. Thus

 s.foo(1)

should call s.foo(long) because that is the only one accessible by the caller anyway.

Okay, so its not C++, so what! If anyone, including existing C++ coders, want to code in D they should learn D.

-- 
Derek Parnell
Melbourne, Australia

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:
"testprivate.cpp `void S::foo(std::string)' is private"

and this to me seems the wrong way around. I don't need nor want to know about other peoples code internals, the ideal message would be: "testprivate.cpp `no public method void S::foo(std::string)"

On Sat, 08 Jul 2006 18:39:15 +1000, Ivan Senji <ivan.senji_REMOVE_@_THIS__gmail.com> wrote:

> s.foo("Bla"); <- atleast in C++(unlike D) this isn't allowed, i got a
> message:
> "testprivate.cpp `void S::foo(std::string)' is private"
>
> and this to me seems the wrong way around. I don't need nor want to know
> about other peoples code internals, the ideal message would be:
> "testprivate.cpp `no public method void S::foo(std::string)"

Yes a much better message.


-- 
Derek Parnell
Melbourne, Australia