www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Module visibility feature?

reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
So I was reading this: 
http://wiki.dlang.org/Access_specifiers_and_visibility



After I went through it, I had an idea for a feature that I hope 
would be both intuitive and not too difficult to implement.

We already have the protection attributes public, private, 
protected, and package. Why not have the ability to apply 
something similar to specific modules?

I thought of two different variations to this concept, but I will 
only post about the one that I feel is less convoluted.

I figured that a single keyword should be able to do the trick, 
and package made the most sense. Here's how I'm theorizing this 
could work. If a module is  declared as a "package module" then 
only other modules in the same package are able to import it, 
essentially the way package works currently. Any attempt to 
import that module outside the package would result in an error.


--foo/barstuff.d
package module foo.barstuff;

//stuff the user never needs to see



--foo/bar.d
module foo.bar;
import foo.barstuff;

void someFunction()
{
      //stuff from foo.barstuff
}



--main.d
module main;
import foo.bar;          //ok!
//import foo.barstuff;   //error!

void main(string[] args)
{
      someFunction();
}



Has anything like this been suggested/thought of before? I looked 
through the DIP's but didn't see anything.
Jul 17 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jeremy DeHaan:

 package module foo.barstuff;

Or this? private module foo.barstuff; Bye, bearophile
Jul 17 2013
prev sibling next sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Wednesday, 17 July 2013 at 11:38:32 UTC, bearophile wrote:
 Jeremy DeHaan:

 package module foo.barstuff;

Or this? private module foo.barstuff; Bye, bearophile

In some sense, I feel like package, private, or protected would all work semantically. I only used package because I was trying to keep things consistent with how that attribute works normally. However it is implemented, I just think having some kind of module visibility attribute(s) would be a nice feature.
Jul 17 2013
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote:
 Has anything like this been suggested/thought of before? I 
 looked through the DIP's but didn't see anything.

I don't know, but I think this is a good suggestion; stronger language support for modules that are an implementation detail of a package. The 'package' keyword you suggested is definitely more logical than 'private'.
Jul 17 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote:
 So I was reading this: 
 http://wiki.dlang.org/Access_specifiers_and_visibility
 ...

How will it be any different from module foo.barstuff; package: // declarations
Jul 18 2013
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Thursday, 18 July 2013 at 10:55:39 UTC, Dicebot wrote:
 On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote:
 So I was reading this: 
 http://wiki.dlang.org/Access_specifiers_and_visibility
 ...

How will it be any different from module foo.barstuff; package: // declarations

All modules can import foo.barstuff, but only other modules in foo could import a module declared as 'protected': protected module foo.detail; // declarations This makes a clearer distinction between implementation detail modules vs normal modules.
Jul 18 2013
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Thursday, 18 July 2013 at 22:22:15 UTC, Tommi wrote:
 All modules can import foo.barstuff, but only other modules in 
 foo could import a module declared as 'protected':

 protected module foo.detail;

 // declarations

 This makes a clearer distinction between implementation detail 
 modules vs normal modules.

'package' rather than 'protected'
Jul 18 2013
prev sibling next sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Thursday, 18 July 2013 at 10:55:39 UTC, Dicebot wrote:
 On Wednesday, 17 July 2013 at 11:33:39 UTC, Jeremy DeHaan wrote:
 So I was reading this: 
 http://wiki.dlang.org/Access_specifiers_and_visibility
 ...

How will it be any different from module foo.barstuff; package: // declarations

This is how I handle this situation currently, and was actually part of the inspiration for this idea. Like Tommi said, it makes a very clear distinction between what the user should and shouldn't be able to interact with. A regular module can still be imported, even though everything it would contain has package visibility. Trying to import a package module and getting an error because of it is like having the compiler say, "There's nothing in here for you!" Also, having a way to specify that a module isn't publicly visible could be used for code completion features in IDE's. If foo.barstuff is a package module, typing "import foo." would show "foo.bar" as the onlyoption for modules they can import.
Jul 19 2013
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
On 07/17/2013 01:33 PM, Jeremy DeHaan wrote:
 So I was reading this:
 http://wiki.dlang.org/Access_specifiers_and_visibility



 After I went through it, I had an idea for a feature that I hope would
 be both intuitive and not too difficult to implement.

http://wiki.dlang.org/DIP22 and https://github.com/D-Programming-Language/dmd/pull/739. I think that the visibility vs. accessibility distinction inherited from C++ is not a good fit for D's module system. For C++ headers are the mean to hide implementation but that is not a good solution for D modules. There are not many reasons to make private symbols visible and I suggested a consistent rule to handle overloads with mixed protection.
Jul 21 2013
prev sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Monday, 22 July 2013 at 01:33:02 UTC, Martin Nowak wrote:
 On 07/17/2013 01:33 PM, Jeremy DeHaan wrote:
 So I was reading this:
 http://wiki.dlang.org/Access_specifiers_and_visibility



 After I went through it, I had an idea for a feature that I 
 hope would
 be both intuitive and not too difficult to implement.

http://wiki.dlang.org/DIP22 and https://github.com/D-Programming-Language/dmd/pull/739. I think that the visibility vs. accessibility distinction inherited from C++ is not a good fit for D's module system. For C++ headers are the mean to hide implementation but that is not a good solution for D modules. There are not many reasons to make private symbols visible and I suggested a consistent rule to handle overloads with mixed protection.

To some degree, these do cover the same kind of thing, but I'm not talking about module members, I'm talking about the module itself. I feel like there should be ways to stop an entire module from even being imported as this clearly says that what ever is in the module is an implementation, and you shouldn't even know that that module exists. Being able to import a module that only contains things that aren't accessible sounds like an odd thing to me.
Jul 22 2013