www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1441] New: Allow 'private' to restrict class visibility outside module or outer class

reply d-bugmail puremagic.com writes:
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


--
Aug 26 2007
next sibling parent d-bugmail puremagic.com writes:
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.


--
Apr 10 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


--
Apr 10 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


--
Apr 10 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


--
Apr 10 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--
Apr 12 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Aug 20 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 18 2012
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 18 2012