• "Carlos Santander B." <carlos8294 msn.com> Sep 12 2003
• Helmut Leitner <helmut.leitner chello.at> Sep 12 2003

"Carlos Santander B." <carlos8294 msn.com> writes:

I don't find this behavior consistent:

-----a.d-----
private:
int x;
alias int integer;
struct A { int w; }
enum B { x,y,z }
class C { }
-----b.d-----
import a;
...
x=4;   // doesn't work
integer p;
A d;
B t;
C h;

While that assignment doesn't work, all the other declarations do. I was
under the impression that if a symbol (any symbol) was private for a module,
no other module could make use of it.

-------------------------
Carlos Santander




---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 2003-09-01

Helmut Leitner <helmut.leitner chello.at> writes:

"Carlos Santander B." wrote:
 
 I don't find this behavior consistent:
 
 -----a.d-----
 private:
 int x;
 alias int integer;
 struct A { int w; }
 enum B { x,y,z }
 class C { }
 -----b.d-----
 import a;
 ...
 x=4;   // doesn't work
 integer p;
 A d;
 B t;
 C h;
 
 While that assignment doesn't work, all the other declarations do. I was
 under the impression that if a symbol (any symbol) was private for a module,
 no other module could make use of it.


I also think there should be a more complete set of possibilities to make
things visible or not.

If a would defend the behaviour above, I'd say:

  'private' is about encapsulation, meaning that the data of an object
  or module is protected against inadvertent change. The use of definitions
  is not risky in this sense, so it is not touched by 'private'.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com