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 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