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