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



 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 2022



 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 2022



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 2022



 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 2022



 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 2022



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 2022



  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 2022



  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 2022



  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 2022



  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 2022



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 2022



 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 2022



  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 2022



  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 2022



  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 2022



  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 2022



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 2022



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 2022