www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Protection attributes on classes/interfaces

reply "John C" <johnch_atms hotmail.com> writes:
Is protection going to be implemented for class and interface declarations? 
I was under the impression that it already was, but a quick test just now 
allowed me to create an instance of a class that is declared private in a 
separate module. The spec seems to indicate that protection only applies to 
module and class members -- any reason for classes and interfaces (or even 
structs) to be exempt from this? 
Sep 16 2005
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
John C wrote:
 Is protection going to be implemented for class and interface declarations? 
 I was under the impression that it already was, but a quick test just now 
 allowed me to create an instance of a class that is declared private in a 
 separate module. The spec seems to indicate that protection only applies to 
 module and class members -- any reason for classes and interfaces (or even 
 structs) to be exempt from this? 
 
 

From the D spec (http://www.digitalmars.com/d/attribute.html): "Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class. Private members cannot be overridden. Private module members are equivalent to static declarations in C programs." I tested this with the offsetof-bug example sent to d.bugs: [test2.d] private class Foo { int x; } [test.d] import test2; void main() { printf("%d",Foo.init.x.offsetof); // no error ?! Foo a = new Foo(); // linker error } --- DMD really seems to ignore private attributes when module members are not "directly" instantiated. One other thing is that there seems to be no compiler logic that could recognise the misuse of attributes. AFAIK it's the linker that complains as it cannot find a correct function signature.
Sep 16 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message 
news:dge9vi$gs0$1 digitaldaemon.com...
 John C wrote:
 Is protection going to be implemented for class and interface 
 declarations? I was under the impression that it already was, but a quick 
 test just now allowed me to create an instance of a class that is 
 declared private in a separate module. The spec seems to indicate that 
 protection only applies to module and class members -- any reason for 
 classes and interfaces (or even structs) to be exempt from this?

From the D spec (http://www.digitalmars.com/d/attribute.html): "Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class. Private members cannot be overridden. Private module members are equivalent to static declarations in C programs." I tested this with the offsetof-bug example sent to d.bugs: [test2.d] private class Foo { int x; } [test.d] import test2; void main() { printf("%d",Foo.init.x.offsetof); // no error ?! Foo a = new Foo(); // linker error }

I can't reproduce your linker error. D 0.131 allows me to new Foo, declared privately in a separate module.
 ---

 DMD really seems to ignore private attributes when module members are not 
 "directly" instantiated. One other thing is that there seems to be no 
 compiler logic that could recognise the misuse of attributes. AFAIK it's 
 the linker that complains as it cannot find a correct function signature. 

Sep 16 2005
parent reply Carlos Santander <csantander619 gmail.com> writes:
John C escribió:
 "Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message 
 news:dge9vi$gs0$1 digitaldaemon.com...
 
John C wrote:

Is protection going to be implemented for class and interface 
declarations? I was under the impression that it already was, but a quick 
test just now allowed me to create an instance of a class that is 
declared private in a separate module. The spec seems to indicate that 
protection only applies to module and class members -- any reason for 
classes and interfaces (or even structs) to be exempt from this?

From the D spec (http://www.digitalmars.com/d/attribute.html): "Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class. Private members cannot be overridden. Private module members are equivalent to static declarations in C programs." I tested this with the offsetof-bug example sent to d.bugs: [test2.d] private class Foo { int x; } [test.d] import test2; void main() { printf("%d",Foo.init.x.offsetof); // no error ?! Foo a = new Foo(); // linker error }

I can't reproduce your linker error. D 0.131 allows me to new Foo, declared privately in a separate module.

Maybe Jari-Matti just forgot to link test2. -- Carlos Santander Bernal
Sep 16 2005
parent "John C" <johnch_atms hotmail.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message 
news:dgfko1$1rab$1 digitaldaemon.com...
 John C escribió:
 "Jari-Matti Mäkelä" <jmjmak invalid_utu.fi> wrote in message 
 news:dge9vi$gs0$1 digitaldaemon.com...

John C wrote:

Is protection going to be implemented for class and interface 
declarations? I was under the impression that it already was, but a 
quick test just now allowed me to create an instance of a class that is 
declared private in a separate module. The spec seems to indicate that 
protection only applies to module and class members -- any reason for 
classes and interfaces (or even structs) to be exempt from this?

From the D spec (http://www.digitalmars.com/d/attribute.html): "Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class. Private members cannot be overridden. Private module members are equivalent to static declarations in C programs." I tested this with the offsetof-bug example sent to d.bugs: [test2.d] private class Foo { int x; } [test.d] import test2; void main() { printf("%d",Foo.init.x.offsetof); // no error ?! Foo a = new Foo(); // linker error }

I can't reproduce your linker error. D 0.131 allows me to new Foo, declared privately in a separate module.

Maybe Jari-Matti just forgot to link test2. -- Carlos Santander Bernal

I've filed this issue under D.bugs.
Sep 17 2005