www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2529] New: 'package' access qualifier should allow access to sub-packages

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2529

           Summary: 'package' access qualifier should allow access to sub-
                    packages
           Product: D
           Version: 1.037
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: spec
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: jarrett.billingsley gmail.com


Currently, a symbol declared as package in "a.b" is only accessible to other
modules in "a", such as "a.c" and "a.d".  But it is not accessible from
"a.sub.x".

The language spec is somewhat unclear on this:

http://www.digitalmars.com/d/1.0/attribute.html

"Package extends private so that package members can be accessed from code in
other modules that are in the same package. This applies to the innermost
package only, if a module is in nested packages. "

What I find unclear is "other modules in the same package."  I see "a.sub.x" as
in the same package as "a.b", since they're both in "a".  

What would this be useful for?  Well as a practical example, I've been working
on the new implementation of MiniD for several months, and as the codebase has
grown, I've accumulated more and more modules.  Now that I have close to 50
modules in one package, I'd like to put them in sub-packages of related
functionality.

The problem is that there is a small set of "universal" functionality which is
needed by the entire library but which I don't want to be accessible from
outside the library.  I can't make it private since then it won't be accessible
from other modules in the library.  I can't make it public because then it
would be accessible from outside the library.  So I'm stuck with package, but
the problem with that is that only modules with the _exact_ same package prefix
as the common functionality can access it.  Thus, all of my modules are forced
into the same package.

What I am proposing is that the "package" qualifier's meaning of "other modules
in the same package" be defined to be "other modules in the same package,
including those in subpackages."  This does not actually even require a spec
change, since this new behavior is consistent with what is stated.  It also
does not break any code, is a simple fix, and without it, I can see a lot of D
libraries and programs being forced into this kind of one-level hierarchy.


--
Dec 20 2008
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2529






I would actually want this to work the other way. I'd like a.sub.x to be
accessible from a.b. Eg database.mysql should be able to use
database.internal.sqlparsing, rather than the other way around. It would seem
wrong to have the lowest-level stuff in the root.

But I agree that the existing 'package' semantics force you to a flat
hierarchy.


--
Jan 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2529






-------


Perhaps we need two changes to the current behaviour:

1. package access applies to sub-packages as well.

2. The package protection attribute accepts an optional argument which
specifies the base package which has access.  In Don's example:

module database.internal.sqlparsing;
package(database) void foo();

This would allow anything under the database package access to foo.


--
Mar 15 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2529


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au



IMHO, this bug should be closed as invalid, because the initial suggestion in
the bug report is completely wrong: it would drive you to put low-level stuff
in the root, and derived stuff in the leaves. Implementing that suggestion
would encourage poor design. 

The current behaviour of 'package' in D seems nearly identical to the one in
Java. Java has the same problem.

Here is a Java proposal to fix the problem, which was ultimately rejected.

http://jcp.org/en/jsr/detail?id=294

"Today designers are forced to declare elements of the program that are needed
by other subparts of the implementation as public - thereby making them
globally accessible, which is clearly suboptimal.
Alternately, the entire implementation can be placed in a single package. This
resolves the issue above, but is unwieldy, and exposes all internals of all
subparts to each other. "

I also found this link to be helpful:

http://stackoverflow.com/questions/403583/what-is-the-use-of-package-level-protection-in-java

---
I can't really escape the feeling that 'package' is a bit of a flawed concept.
The problems with it don't seem easy to fix.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 04 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2529




Having thought about this a bit more, I think that a much better approach would
be a property applied to module declaration.

 internal
module cleverdb.mysql.funkystuff;

The property would mean, this module can only be imported from modules in
cleverdb.*

Then, everything in that module could be made public to the hierarchy, without
exposing it to the whole world. Thus, some level of encapsulation would be
preserved.

That's not an actual proposal, the point is just that closing this bug would
not mean that the original use case would never be addressed: there are other
possible solutions without changing the meaning of 'package'.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 06 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2529


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



18:00:14 PST ---


 IMHO, this bug should be closed as invalid, because the initial suggestion in
 the bug report is completely wrong: it would drive you to put low-level stuff
 in the root, and derived stuff in the leaves. Implementing that suggestion
 would encourage poor design. 


Agreed, applies to D2 now as well.

Also, package can actually be abused because it doesn't apply to actual
folders, it only applies to module declarations. This means you can fake your
way into getting access simply by re-creating the package folder structure and
use an import switch to introduce the new modules:

/a/m.d:
module a.m;
package void foo() { }

/a/user/a/workaround.d:
module a.workaround;
import a.m;
auto foo()
{
    return a.m.foo();  // free access!
}

/a/user/main.d:
module main;
import a.workaround;
void main()
{
    foo();
}

$ rdmd user\main.d -Iuser

No compile errors!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 23 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2529




18:02:19 PST ---



 /a/user/a/workaround.d:


Should be /user/a/workaround.d


 /a/user/main.d:


Should be /user/main.d

Anyway I'm filing this as another bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 23 2013