www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Private classes?

reply Nathan Reed <nathaniel.reed gmail.com> writes:
Hello,

I'm not sure if this is the appropriate mailing list on which to post this, so
please tell me if it's not.

I have been playing around with D in the last few days and found that there
doesn't seem to be any way to hide a class in a module using 'private'.  For
example, using the DMD version 2.003, the following compiles without errors:

module A;
private class Foo
{
}
------------
module B;
import A;
...
auto f = new Foo;    // expected: error, Foo is private

If A has a privately declared *variable* and I try to access it from B, I get
the expected error.

The same thing happens with inner classes; the following compiles without
errors:

class Foo
{
    private class Bar
    {
    }
}
...
auto f = new Foo;
auto b = f.new Bar;   // expected: error, Bar is private

Now, I can't find anyplace in the D spec where it says that 'private' ought to
work on classes...so I suppose this isn't technically a bug.  However, it seems
like the sort of thing that one ought to be able to do.

Thanks,
Nathan Reed
Aug 21 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
Nathan Reed wrote:
 Hello,
 
 I'm not sure if this is the appropriate mailing list on which to post
 this, so please tell me if it's not.

digitalmars.D.learn might be better in this case. Once you've used D more you'll get a feel for which list to post in in any given case.
 I have been playing around with D in the last few days and found that
 there doesn't seem to be any way to hide a class in a module using
 'private'.  For example, using the DMD version 2.003, the following
 compiles without errors:
 
 module A; private class Foo { } ------------ module B; import A; ... 
 auto f = new Foo;    // expected: error, Foo is private

Try this: [pclassA.d] module pclassA; class A { private this() { } } [pclassB.d] module pclassB; import pclassA; void main() { A a = new A(); }
 If A has a privately declared *variable* and I try to access it from
 B, I get the expected error.
 
 The same thing happens with inner classes; the following compiles
 without errors:
 
 class Foo { private class Bar { } } ... auto f = new Foo; auto b =
 f.new Bar;   // expected: error, Bar is private

Assuming these are in different modules, as in your first example. You can apply private to the constructor for Bar to prevent construction.
 Now, I can't find anyplace in the D spec where it says that 'private'
 ought to work on classes...so I suppose this isn't technically a bug.
 However, it seems like the sort of thing that one ought to be able to
 do.

AFAIK you cannot apply 'private' to a class. Regan
Aug 21 2007
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
Regan Heath escribió:
 Nathan Reed wrote:
 AFAIK you cannot apply 'private' to a class.

Is this because it's not implemented in DMD, or because you can't effectively hide a class from a module? It seems like a bug to me.
 
 Regan

Aug 21 2007
parent Regan Heath <regan netmail.co.nz> writes:
Ary Manzana wrote:
 Regan Heath escribió:
 Nathan Reed wrote:
 AFAIK you cannot apply 'private' to a class.

Is this because it's not implemented in DMD, or because you can't effectively hide a class from a module? It seems like a bug to me.

There were 2 modules involved so it's not related to 'private' having no effect within a module. I think 'private class' is simply un-implemented and should result in an error until such time as it is implemented. I suspect the default compiler behaviour is to simply ignore meaningless keywords, perhaps to aid in generic programming/templates. Not sure. Regan
Aug 21 2007
prev sibling next sibling parent Regan Heath <regan netmail.co.nz> writes:
Henning Hasemann wrote:
 AFAIK you cannot apply 'private' to a class.

So if a 'private' is completely ignored at this place shouldnt this generate a warning/error during compilation?

If 'private class' is meaningless then I would expect a compiler error. I can't see a bugzilla for this, but I'm sure it's come up before so I'm not sure whether one should be filed or not. Perhaps we wait a bit and see if anyone else can recall. Regan
Aug 21 2007
prev sibling next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Regan Heath wrote:

 AFAIK you cannot apply 'private' to a class.

You can and making a class private means it's Ddoc won't be generated, so the protection attribute isn't fully ignored. The spec isn't very clear on this though. It only says: "Private module members are equivalent to static declarations in C programs." But since C doesn't have either templates or classes and type declarations can not be static in C the spec could be clearer here. The logical behavior would be that private module members are accessible from that module only. Even better if they were visible from that module only too. I'd classify it as a compiler bug unless Walter explicitly states it is not. :) -- Oskar
Aug 21 2007
prev sibling parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
Regan Heath Wrote:

 Try this:
 
 [pclassA.d]
 module pclassA;
 
 class A
 {
 	private this()
 	{
 	}
 }

Thanks, I am aware of the private constructor trick, but it seems like a slightly hackish workaround. Philosophically, it seems to me that it should be possible to hide a class so other modules (or code outside its outer class) don't even know it exists - this just makes it so they can't instantiate it. Thanks, Nathan Reed
Aug 21 2007
parent Charles D Hixson <charleshixsn earthlink.net> writes:
Nathan Reed wrote:
 Regan Heath Wrote:
 
 Try this:

 [pclassA.d]
 module pclassA;

 class A
 {
 	private this()
 	{
 	}
 }

Thanks, I am aware of the private constructor trick, but it seems like a slightly hackish workaround. Philosophically, it seems to me that it should be possible to hide a class so other modules (or code outside its outer class) don't even know it exists - this just makes it so they can't instantiate it. Thanks, Nathan Reed

the meaning of private in D. private means "not visible outside of the file in which it is declared". (Well, actually I think it's supposed to be module rather than file, but I always program as if the two were synonymous, so any mistakes this causes aren't noticed by me. As such, I agree that private classes, should they exist (and why not?) shouldn't be visible outside of the module (file?) in which they are declared. This would allow two classes in different modules to have the same name. But note that mangling would mean that their names weren't the same anyway. Stylistically I'd support private classes, but I don't consider the concept important.
Aug 21 2007
prev sibling parent Henning Hasemann <hhasemann web.de> writes:
 AFAIK you cannot apply 'private' to a class.

So if a 'private' is completely ignored at this place shouldnt this generate a warning/error during compilation? Henning -- GPG Public Key: http://keyserver.ganneff.de:11371/pks/lookup?op=get&search=0xDDD6D36D41911851 Fingerprint: 344F 4072 F038 BB9E B35D E6AB DDD6 D36D 4191 1851
Aug 21 2007