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