September 12, 2003 privates at module level | ||||
---|---|---|---|---|
| ||||
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 |
September 13, 2003 Re: privates at module level | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carlos Santander B. | "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 |
Copyright © 1999-2021 by the D Language Foundation