• Zarathustra (16/16) Dec 22 2009 Why protection attributes aren't divided into two groups?
• Rainer Deyke (6/7) Dec 22 2009 Because they're complicated enough already. Because there is no valid
• Zarathustra (42/46) Dec 23 2009 It is complicated because current way is illogical, look:
• Sergey Gromov (8/13) Dec 23 2009 Encapsulation anyone? If you pack related functionality into a single

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?

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

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)

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.