import concerns (was Re: Historical language survey)

Ivan Senji ivan.senji_REMOVE_ at _THIS__gmail.com
Sat Jul 8 01:39:15 PDT 2006


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






More information about the Digitalmars-d mailing list