Walter Bright wrote:
> 
> 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.

This would only occur if both overloads of foo occurred in the same module, correct?  How is that different from the way things work now? Or is the issue simply that in the face of a "true" private mechanism, such behavior would be even more confusing?


Sean

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

In D though, 'private' always implies module visibility, whether it it at module scope or class scope.  If the behavior at module scope is changed, would it affect its behavior at class scope as well?


Sean

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.

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

-- 
Derek Parnell
Melbourne, Australia

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.

-- 
Derek Parnell
Melbourne, Australia

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

> Walter Bright wrote:
>> Brad Roberts wrote:
> [snip]
>>> 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.
>
>
> 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.

That why I wrote http://www.users.bigpond.com/ddparnell/attr.html but no one has bothered to comment it yet - including Walter whom I explicitly asked to.

-- 
Derek Parnell
Melbourne, Australia

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.

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


But currently it doesn't so does that mean currently DMD has this as a bug in it?

-----mod.d----
private int foo;

----test.d----
import foo;

int x = foo.x; // access to a private member is allowed but it shouldn't be!!!


-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> That why I wrote http://www.users.bigpond.com/ddparnell/attr.html but no one has bothered to comment it yet - including Walter whom I explicitly asked to.

I think it's a lot better than what I wrote about it.

Derek Parnell wrote:
> On Sat, 08 Jul 2006 15:18:42 +1000, kris <foo@bar.com> wrote:
> 
>> Walter Bright wrote:
>>
>>> Brad Roberts wrote:
>>
>> [snip]
>>
>>>> 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.
>>
>>
>>
>> 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.
> 
> 
> That why I wrote http://www.users.bigpond.com/ddparnell/attr.html but no  one has bothered to comment it yet - including Walter whom I explicitly  asked to.
> 

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

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.

-- 
Derek Parnell
Melbourne, Australia