question/suggestion about protection attributes
Zarathustra
adam.chrapkowski at gmail.com
Wed Dec 23 04:07:16 PST 2009
Rainer Deyke Wrote:
> Because they're complicated enough already. Because there is no valid
> reason for protecting fields from functions in the same module. And
> because "private public" sounds incredibly stupid.
>
It is complicated because current way is illogical, look:
module b.a;
class Foo{
private void func(){ ... }
package void f(){ ... }
}
class Bar : Foo{
override void func(){ ... } // error cannot delivery inside module only
}
module b.c;
class C : Foo{
override void f(){ ... } // error cannot delivery inside package only
}
OR:
class A{
protected int a;
}
class B{
A a;
void func () { a.a = 2; } // illogical! B is not delivered from A
}
At now protected and private are same inside module for data members,
but not for method!
OR
module a;
class A{
package void func() {}
}
class B : A{
override void func () { } // error: cannot override, because?
}
Because package and private inside module is same!
The problem is that in D there are two types of protection:
1. visibility: private, package, public
2. heredity: virtual, not virtual
and then:
private: not virtual, private(inside one module only)
public: virtual, public(inside all modules)
package: not virtual, package(all modules inside package)
protected: virtual, private(inside one module only); virtual, protected(inside all other modules)! illogical! (protected works erratic)
More information about the Digitalmars-d
mailing list