www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Inner Modules?

reply forkit <forkit gmail.com> writes:
so you can have classes within classes (inner classes).

how about modules within modules (inner modules)?

why? as a means to enforce private 'within' a module.

// -----

module test;

inner module myClasses
{
     class Foo
     {
         // private to the inner module
         private int _num;
     }
}

void main()
{
     Foo f = new test.myClasses.Foo();
     f._num++; // nope!
}

// ---
Feb 12
parent reply forkit <forkit gmail.com> writes:
On Saturday, 12 February 2022 at 19:29:05 UTC, forkit wrote:

oh. the motivation for this?

to not have to put your class in a separate module, just to 
enforce private.
Feb 12
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 12 February 2022 at 19:37:49 UTC, forkit wrote:
 On Saturday, 12 February 2022 at 19:29:05 UTC, forkit wrote:

 oh. the motivation for this?

 to not have to put your class in a separate module, just to 
 enforce private.
Yeah people who reads the forum know what you are talking about. This is an old chesnut here.
Feb 12
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 12 February 2022 at 19:48:23 UTC, Basile B. wrote:
 On Saturday, 12 February 2022 at 19:37:49 UTC, forkit wrote:
 On Saturday, 12 February 2022 at 19:29:05 UTC, forkit wrote:

 oh. the motivation for this?

 to not have to put your class in a separate module, just to 
 enforce private.
Yeah people who reads the forum know what you are talking about. This is an old chesnut here.
*chestnut
Feb 12
prev sibling parent reply forkit <forkit gmail.com> writes:
On Saturday, 12 February 2022 at 19:48:23 UTC, Basile B. wrote:
 Yeah people who reads the forum know what you are talking about.
 This is an old chesnut here.
I don't get it. This is not a valid topic for discussion?
Feb 12
next sibling parent reply forkit <forkit gmail.com> writes:
On Saturday, 12 February 2022 at 21:23:08 UTC, forkit wrote:
 On Saturday, 12 February 2022 at 19:48:23 UTC, Basile B. wrote:
 Yeah people who reads the forum know what you are talking 
 about.
 This is an old chesnut here.
I don't get it. This is not a valid topic for discussion?
I got the idea from Rust: https://doc.rust-lang.org/rust-by-example/mod/visibility.html
Feb 12
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 12 February 2022 at 21:25:48 UTC, forkit wrote:
 On Saturday, 12 February 2022 at 21:23:08 UTC, forkit wrote:
 On Saturday, 12 February 2022 at 19:48:23 UTC, Basile B. wrote:
 Yeah people who reads the forum know what you are talking 
 about.
 This is an old chesnut here.
I don't get it. This is not a valid topic for discussion?
I got the idea from Rust: https://doc.rust-lang.org/rust-by-example/mod/visibility.html
This exists in other languages too. In styx I've chosen ["strict"](https://styx-lang.gitlab.io/styx/protection_decla ation.html#strict), inspired by the keyword used in free pascal, that has ["strict private"](https://www.freepascal.org/docs-html/ref/refse35.html).
Feb 12
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
Modules originate in ML.

Which do something very similar as they are not tied to files.
Feb 12
parent reply forkit <forkit gmail.com> writes:
On Saturday, 12 February 2022 at 22:18:19 UTC, rikki cattermole 
wrote:
 Modules originate in ML.

 Which do something very similar as they are not tied to files.
That's interesting. I will look into that (ML). btw. Do you think, that since D modules are 'tied to files', that 'inner modules concept' would be to difficult/complex to ever implement in D?
Feb 12
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 13/02/2022 11:23 AM, forkit wrote:
 On Saturday, 12 February 2022 at 22:18:19 UTC, rikki cattermole wrote:
 Modules originate in ML.

 Which do something very similar as they are not tied to files.
That's interesting. I will look into that (ML). btw. Do you think, that since D modules are 'tied to files', that 'inner modules concept' would be to difficult/complex to ever implement in D?
It would be a major refactoring to allow multiple modules per file. It would have to be implemented as a separate thing in the compiler, I think.
Feb 12
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 12 February 2022 at 22:26:58 UTC, rikki cattermole 
wrote:
 It would be a major refactoring to allow multiple modules per 
 file.
the compiler already does it, to some extent, for mixins. it should be easy to implement.
Feb 12
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 13/02/2022 11:30 AM, Adam D Ruppe wrote:
 On Saturday, 12 February 2022 at 22:26:58 UTC, rikki cattermole wrote:
 It would be a major refactoring to allow multiple modules per file.
the compiler already does it, to some extent, for mixins. it should be easy to implement.
I'm glad to be wrong, would be an interesting experiment if that is the case.
Feb 12
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 12 February 2022 at 21:23:08 UTC, forkit wrote:
 On Saturday, 12 February 2022 at 19:48:23 UTC, Basile B. wrote:
 Yeah people who reads the forum know what you are talking 
 about.
 This is an old chesnut here.
I don't get it. This is not a valid topic for discussion?
No it's just that this topic comes back every 3 monthes. You'll be said that D bases its system of visibility attribute on modules and that you'll have to live with that. Personnally I have nothing against such a feature, in addition to module-based privacy, but honestly I think this is an unimportant detail. As for the syntax I'd prefer something based on "private", e.g "private(strict)", or even "strict" as a soft-keyword if it's located right before "private" and as a regular identifier otherwise.
Feb 12
next sibling parent reply forkit <forkit gmail.com> writes:
On Saturday, 12 February 2022 at 21:39:37 UTC, Basile B. wrote:
 On Saturday, 12 February 2022 at 21:23:08 UTC, forkit wrote:
 On Saturday, 12 February 2022 at 19:48:23 UTC, Basile B. wrote:
 Yeah people who reads the forum know what you are talking 
 about.
 This is an old chesnut here.
I don't get it. This is not a valid topic for discussion?
No it's just that this topic comes back every 3 monthes.
That's interesing. Walter himself acknowleges there is a case for denying access to private members 'even within a module' - in his article: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ He provides an explanation of how to go about doing that - ie. 'the package module' (essentially, split modules into smaller ones). I am of the same opinion here as Walter, except, 'possibly' there is simpler way to achieve this, by the use of inner modules, where the same rules apply as they currently apply to modules.
Feb 12
parent reply bachmeier <no spam.net> writes:
On Saturday, 12 February 2022 at 21:52:41 UTC, forkit wrote:

 Walter himself acknowleges there is a case for  denying access 
 to private members 'even within a module' - in his article: 
 https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

 He provides an explanation of how to go about doing that - ie. 
 'the package module' (essentially, split modules into smaller 
 ones).

 I am of the same opinion here as Walter, except, 'possibly' 
 there is simpler way to achieve this, by the use of inner 
 modules, where the same rules apply as they currently apply to 
 modules.
[This was probably the most recent discussion](https://forum.dlang.org/post/tomtejfkfcqdtmzeouvg forum.dlang.org). If you really don't want to handle it that way, you can write a short script to automate the splitting of your files prior to compilation. My impression, which may be wrong, is that nobody's ever made a strong case that this issue is a sufficient problem to warrant yet another addition to an already large and growing language.
Feb 12
parent reply forkit <forkit gmail.com> writes:
On Saturday, 12 February 2022 at 22:03:08 UTC, bachmeier wrote:
 ..
 My impression, which may be wrong, is that nobody's ever made a 
 strong case
 that this issue is a sufficient problem to warrant yet another 
 addition
 to an already large and growing language.
Oh. I'm not trying to make that case ;-) Let's put 'the case' aside for now ;-) I'm just exploring at 'a conceptual level', how to retain private visibility within a module without having to split it into 'separate files'. Conceptually, nothing changes really. You end up creating mulitple modules either way (whether in separate files, or within inner modules). None of the language rules would change, with regards to modules, as I see it, (conceptually).
Feb 12
parent reply forkit <forkit gmail.com> writes:
On Saturday, 12 February 2022 at 22:33:25 UTC, forkit wrote:
 I'm just exploring at 'a conceptual level', how to retain 
 private visibility within a module without having to split it 
 into 'separate files'.
Actually, there's more to it, that I'm looking for: - Stronger encapsulation within components, contained within a module. - Enscapsulating all the information needed within a module, within a single file. It seems the only practical way to achieve the above, *without* changing language rules with regards to modules/visibility etc, is through an inner modules concept. Again, conceptually only (I'm not making the case that D should actually do this).
Feb 12
parent forkit <forkit gmail.com> writes:
On Saturday, 12 February 2022 at 22:51:58 UTC, forkit wrote:

As a demonstration:

.. the superpower of Rust's inner modules (even when using 
'unsafe'):

// ---



fn main() {
     unsafe {
         innerModule::SIZE = 10; // compile time error -> static 
`SIZE` is private
     }
}

// Remember, private is default in Rust.
// So both this innerMod and the static var SIZE are both private.
//
mod innerModule {
     // annotate below pub to make it accessible outside this 
inner module.
     static mut SIZE: i32 = 5;
}

// -----

More very interesting analysis here:

https://iximiuz.com/en/posts/rust-privacy-and-visibility/
Feb 12
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 12, 2022 at 09:39:37PM +0000, Basile B. via Digitalmars-d wrote:
[...]
 No it's just that this topic comes back every 3 monthes.
 
 You'll be said that D bases its system of visibility attribute on
 modules and that you'll have to live with that.
[...] Do we really have to live with it? Proof-of-concept: -------- auto makeObj() { int x = 1; int y = 2; struct Result { int getX() { return x; } void setX(int newX) { x = (x >= 0) ? newX : 0; } int getY() { return y; } } return Result(); } void main() { import std; auto obj = makeObj(); writeln(obj.getX); obj.setX(3); writeln(obj.getX); writeln(obj.getY); writeln(obj.getX); //obj.x = 1; // Error: no property `x` for type `test.makeObj.Result` } -------- Et voila! Now there is no way for anybody except the methods of Result to touch the values x and y. (And note that the struct has no state except the hidden context pointer, so it essentially behaves like a class.) Now, I'm not saying this is necessarily a *good* solution. (It probably opens up a whole slew of other problems. :-D) But it *can* be done, if you're really *that* desperate. Me, I just live with module-private and a few extra files. It's not the end of the world, there are ways of coping with it. And module-private can be really a good thing in situations where C++ needs friends. T -- Let's call it an accidental feature. -- Larry Wall
Feb 12
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Saturday, 12 February 2022 at 19:37:49 UTC, forkit wrote:
 oh. the motivation for this?

 to not have to put your class in a separate module, just to 
 enforce private.
Another use case for this is when you want a namespace inside a module with other top-level declarations. This is actually done for `core.memory` with a hack. There is a `struct GC` with ` disable this();` and only static members: https://dlang.org/phobos/core_memory.html#.GC It would be much nicer for the docs and code if an inner module could be used instead: ```d module core.memory; ... module GC { nothrow void enable(); nothrow void disable(); ... } ```
Feb 13