View previous topic :: View next topic |
Author |
Message |
Reedbeta
Joined: 19 Aug 2007 Posts: 5 Location: Claremont, CA
|
Posted: Sun Aug 19, 2007 3:48 pm Post subject: Private classes - possible D compiler bug? |
|
|
Code: | module A;
private class Foo
{
} |
Code: | import A;
int main (char[][] args)
{
Foo f = new Foo;
return 0;
} |
This compiles with no errors...which I don't think is right since I shouldn't be able to access Foo outside module A.
I get the expected compile error if I add a private constructor to Foo, but this seems ugly to me. I should be able to hide a class entirely so other modules don't even know it exists.
Same thing happens with nested classes - the following compiles without errors:
Code: | class Foo
{
private static class Bar
{
}
}
int main (char[][] args)
{
Foo.Bar b = new Foo.Bar;
return 0;
} |
Any ideas? |
|
Back to top |
|
|
grignaak
Joined: 25 May 2007 Posts: 9 Location: Seattle
|
Posted: Thu Aug 23, 2007 11:41 pm Post subject: |
|
|
I agree. This is a bug.
Which compiler are you using? |
|
Back to top |
|
|
Reedbeta
Joined: 19 Aug 2007 Posts: 5 Location: Claremont, CA
|
Posted: Fri Aug 24, 2007 12:01 am Post subject: |
|
|
DMD 2.003. |
|
Back to top |
|
|
grignaak
Joined: 25 May 2007 Posts: 9 Location: Seattle
|
Posted: Fri Aug 24, 2007 12:42 am Post subject: |
|
|
I suggest you create a ticket on digitalmars' site. (You do know that D 2.0 is still in alpha? I mean we are still discussing today what are possible features to add to it)
Regards
--Michael |
|
Back to top |
|
|
Reedbeta
Joined: 19 Aug 2007 Posts: 5 Location: Claremont, CA
|
Posted: Fri Aug 24, 2007 9:06 am Post subject: |
|
|
Yes, I know it is still in alpha - and I hope this can be a feature that gets in, as it seems quite a simple one. I'll make a ticket. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Fri Aug 24, 2007 10:08 am Post subject: |
|
|
This has been brought up many, many times before on the newsgroup. It's not really a bug, since protection attributes don't affect class declarations. If you need to restrict class creation to a certain module, give it a private constructor:
Code: |
class MyClass
{
private this() { ... }
}
|
_________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
Reedbeta
Joined: 19 Aug 2007 Posts: 5 Location: Claremont, CA
|
Posted: Sun Aug 26, 2007 11:47 am Post subject: |
|
|
As I've also posted on the newsgroup:
Quote: |
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. |
|
|
Back to top |
|
|
Rommie
Joined: 23 Aug 2007 Posts: 6
|
Posted: Sun Aug 26, 2007 6:45 pm Post subject: |
|
|
You can always do
Code: |
class VisibleClass
{
class InvisibleClass
{
// stuff
}
// code here can see InvisibleClass
}
// code here cannot
|
It's a bit of a sneak. The outside world actually can see the nested class, but with a convoluted name. Still, unless you expect the outside world to be doing new VisibleClass.InvisibleClass() it's private enough. |
|
Back to top |
|
|
Reedbeta
Joined: 19 Aug 2007 Posts: 5 Location: Claremont, CA
|
Posted: Sun Aug 26, 2007 7:19 pm Post subject: |
|
|
That's true; at least with nested classes, the outer namespace is not polluted. But the namespace pollution still takes place at the module level, and the class is still not prevented from being instantiated (unless you use a private ctor)... |
|
Back to top |
|
|
|