Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 26, 2007 [Issue 1441] New: Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=1441 Summary: Allow 'private' to restrict class visibility outside module or outer class Product: D Version: 2.003 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: bugzilla@digitalmars.com ReportedBy: nathaniel.reed@gmail.com Currently, there is no way to restrict a class from being visible outside the module where it is defined, or for inner classes, outside its outer class. This isn't a bug, more of a feature request, but it would be nice to be able to use 'private' on a class to hide its visibility: module A; private class Foo { ... } module B; import A; Foo f = new Foo; // error, Foo is private also: class Foo { private static class Bar { ... } ... } Foo.Bar b = new Foo.Bar; // error, Bar is private I know a private constructor can be used to prevent a class's *instantiation* from another module, but this seems like a hackish workaround to me. Modules should be able to prevent their classes from being visible in another module for at least two reasons: 1. Encapsulation: for the same reasons that private methods of a class aren't visible when its containing module is imported, classes that are part of the implementation of the module aren't visible when the module is imported. 2. Namespace pollution: modules can prevent names that are part of their implementation from unneccessarily entering the namespace of an importing module. The same applies to inner classes. Thanks, Nathan Reed -- |
April 10, 2009 [Issue 1441] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 smjg@iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smjg@iname.com Keywords| |accepts-invalid ------- Comment #1 from smjg@iname.com 2009-04-10 12:40 ------- This has resurfaced as issue 2830. I say this is a bug - the compiler shouldn't be allowing the use of attributes that aren't meant to work. -- |
April 10, 2009 [Issue 1441] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 ------- Comment #2 from jarrett.billingsley@gmail.com 2009-04-10 14:05 ------- That's an entirely separate issue from this enhancement request. The spec also does not say that 'pointless' attributes should trigger an error, so I don't see how it's "accepts-invalid" at all. -- |
April 10, 2009 [Issue 1441] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 ------- Comment #3 from smjg@iname.com 2009-04-10 14:34 ------- (In reply to comment #2) > That's an entirely separate issue from this enhancement request. The spec also does not say that 'pointless' attributes should trigger an error, so I don't see how it's "accepts-invalid" at all. 1. http://www.digitalmars.com/d/2.0/attribute.html#ProtectionAttribute talks of "members". Should we interpret this to include arbitrary members of a module? 2. Where does the spec state that it's legal to use attributes that are not applicable to the entity to which they're applied? Otherwise it's reasonable to assume that, should the compiler fail in its attempt to apply an attribute to something, this failure is supposed to be by means of generating an error. 3. Making a class or similar entity private makes perfect sense. Silently ignoring attempts to do so makes absolutely none. -- |
April 10, 2009 [Issue 1441] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 ------- Comment #4 from jarrett.billingsley@gmail.com 2009-04-10 14:45 ------- (In reply to comment #3) > 1. http://www.digitalmars.com/d/2.0/attribute.html#ProtectionAttribute > talks of "members". Should we interpret this to include arbitrary members of a > module? Sure. That's more or less what this ticket is suggesting. > 2. Where does the spec state that it's legal to use attributes that are not applicable to the entity to which they're applied? Otherwise it's reasonable to assume that, should the compiler fail in its attempt to apply an attribute to something, this failure is supposed to be by means of generating an error. Two problems. One, the spec is silent on this issue, so it's logically inconsistent to conclude that by not issuing an error, the compiler is acting incorrectly. In effect there is no "correct" behavior because there is no specified behavior; assumptions mean nothing. Two, if you want the compiler to give an error about inapplicable attributes, put it in another ticket. That particular behavior encompasses far more than just public and private on classes, but also things like final, static, extern etc. > 3. Making a class or similar entity private makes perfect sense. Silently ignoring attempts to do so makes absolutely none. Again, what the compiler should do with inapplicable attributes is a separate issue from what 'private' on a class should mean. This ticket is an enhancement request; your request is more one for clarification of the spec. -- |
April 12, 2009 [Issue 1441] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 ------- Comment #5 from smjg@iname.com 2009-04-12 17:53 ------- Discussion taken to: "The great inapplicable attribute debate" digitalmars.D:87915 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=87915 -- |
August 21, 2011 [Issue 1441] [module] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 Christian Kamm <kamm-removethis@incasoftware.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich@gmail.com --- Comment #6 from Christian Kamm <kamm-removethis@incasoftware.de> 2011-08-20 23:22:20 PDT --- *** Issue 6180 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
February 18, 2012 [Issue 1441] [module] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 --- Comment #7 from github-bugzilla@puremagic.com 2012-02-18 11:04:42 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a75022643a7f6758074f8b107a2c37eb1231e3f8 fixed Issue 1441 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
February 18, 2012 [Issue 1441] [module] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 --- Comment #8 from github-bugzilla@puremagic.com 2012-02-18 11:47:24 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e37a34ff5afdd41a2f064a318f5696394a43e9fc Revert "fixed Issue 1441" This reverts commit a75022643a7f6758074f8b107a2c37eb1231e3f8. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
October 18, 2012 [Issue 1441] [module] Allow 'private' to restrict class visibility outside module or outer class | ||||
---|---|---|---|---|
| ||||
Posted in reply to d-bugmail | http://d.puremagic.com/issues/show_bug.cgi?id=1441 Oleg Kuporosov <Oleg.Kuporosov@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Oleg.Kuporosov@gmail.com OS/Version|Linux |All Severity|enhancement |major --- Comment #9 from Oleg Kuporosov <Oleg.Kuporosov@gmail.com> 2012-10-18 02:33:19 PDT --- From original Nathan's post there are 2 cases, first looks similar to http://d.puremagic.com/issues/show_bug.cgi?id=2830 (originally for D2 and now for D1 only) The fix from commit https://github.com/D-Programming-Language/dmd/commit/6a8be065d8eda64318643147704aebdcc22fd7b8 effectivelly solves the issue on module level for D2.061 alpha. The same time for the case of private nested classes which are still accessable outside of enclosing class and module. The behaviour should follow "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." in http://dlang.org/attribute.html. While this effectively allows access to private nested members from inside the same module, http://dlang.org/class.html "A nested class is a class that is declared inside the scope of a function or another class" closing visibility and access to nested members outside of function or enclosing class even the same module. The issue is moved from "enhancement" to the bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
Copyright © 1999-2021 by the D Language Foundation