www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - question/suggestion about protection attributes

reply Zarathustra <adam.chrapkowski gmail.com> writes:
Why protection attributes aren't divided into two groups?
I mean:
module : package, private
class: protected, public

Then will be possible to set:
package protected - accessible for subclasses inside package
package public       - accessible in package (simply package)

private protected   - accessible for subclasses inside module
private public         - accessible in module (simply private)

A great idea is change private to class only, instead module and improve
package (or other keyword) to:
package - module scope (private at now)
package(package_name) - some package visibility ex:

module a.b.c;

module a.d;

package (a) int var; - var is accessible for any module inside 'a' package.

What do you thing about it?
Dec 22 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Zarathustra wrote:
 Why protection attributes aren't divided into two groups?

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. -- Rainer Deyke - rainerd eldwood.com
Dec 22 2009
next sibling parent Zarathustra <adam.chrapkowski gmail.com> writes:
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)
Dec 23 2009
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Rainer Deyke wrote:
 Zarathustra wrote:
 Why protection attributes aren't divided into two groups?

... Because there is no valid reason for protecting fields from functions in the same module...

Encapsulation anyone? If you pack related functionality into a single module you don't have *any* means of enforcing encapsulation at the language level. "private" becomes a pure convention. And if you use modules to systematically enforce encapsulation you end up with Tango: dozens of micro-modules which require either dozens of imports to use them, or ugly collective import modules which require constant attention and maintenance.
Dec 23 2009