digitalmars.D - Module visibility feature?
- Jeremy DeHaan (35/35) Jul 17 2013 So I was reading this:
- bearophile (5/6) Jul 17 2013 Or this?
- Jeremy DeHaan (6/12) Jul 17 2013 In some sense, I feel like package, private, or protected would
- Tommi (5/7) Jul 17 2013 I don't know, but I think this is a good suggestion; stronger
- Dicebot (5/8) Jul 18 2013 How will it be any different from
- Tommi (7/15) Jul 18 2013 All modules can import foo.barstuff, but only other modules in
- Tommi (2/8) Jul 18 2013 'package' rather than 'protected'
- Jeremy DeHaan (13/21) Jul 19 2013 This is how I handle this situation currently, and was actually
- Martin Nowak (9/13) Jul 21 2013 There is
- Jeremy DeHaan (9/28) Jul 22 2013 To some degree, these do cover the same kind of thing, but I'm
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
Jeremy DeHaan:package module foo.barstuff;Or this? private module foo.barstuff; Bye, bearophile
Jul 17 2013
"Jeremy DeHaan" <dehaan.jeremiah gmail.com> On Wednesday, 17 July 2013 at 11:38:32 UTC, bearophile wrote:Jeremy DeHaan: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.package module foo.barstuff;Or this? private module foo.barstuff; Bye, bearophile
Jul 17 2013
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
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
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: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.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
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
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: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.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 19 2013
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.There is 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
On Monday, 22 July 2013 at 01:33:02 UTC, Martin Nowak wrote:On 07/17/2013 01:33 PM, Jeremy DeHaan wrote: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.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.There is 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 22 2013