www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Scope modules DIP rough messy draft.

reply 12345swordy <alexanderheistermann gmail.com> writes:
https://github.com/12345swordy/DIPs/blob/Encapsulation/DIPs/DIPxxxx.md
Yea, yea, I know it format wise it a giant mess, but I got start 
somewhere don't I?
Oct 26 2018
next sibling parent reply luckoverthere <luckoverthere gmail.cm> writes:
On Saturday, 27 October 2018 at 00:20:33 UTC, 12345swordy wrote:

 https://github.com/12345swordy/DIPs/blob/Encapsulation/DIPs/DIPxxxx.md
 Yea, yea, I know it format wise it a giant mess, but I got 
 start somewhere don't I?


I don't know the rationale to me seems weak:


 Using D as a scripting language becomes more complicated to use 
 for one time scripts as you have to deal with multiple files if 
 you design the classes/structs to be encapsulated by 
 themselves. Where it would be idealy for the scripter to just 
 to handle one file instead of mutiple files.


Why do "one time scripts" need this feature? They will be used 
one time, no? Why do you need to follow encapsulation for a 
script you will run once? It will be small enough that you  can 
read all the code and know what it does.


 Porting from C++ to D involves refactoring, when the programmer 
 should be avoiding refactoring as much as possible during the 
 porting process, as refactoring during the port process can 
 lead to unintended bugs.


D is less restrictive than C++, because it is less restrictive 
you don't need to refactor. There also is no equivalent "friend" 
feature in D. Since you are just copying and pasting code, for 
the most part, where are you going to accidentally call a private 
function you weren't calling before in C++ that you are now going 
to call in D.


 Rapidly creating a program that involves multiple modules 
 requires multiple files for it, which can cause the slow down 
 the coding process, most noticeably in coding competition.


Again encapsulation is to aid in creation and maintenance of 
large code bases for longevity sake. Why would you be worried 
about encapsulation in a coding competition, most likely the 
fastest code aren't going to be following any sort of best 
practice as the fastest code will probably be using some crazy 
hacks anyways.


 It sometimes it easier to put every module in a single file for 
 a simple small program.


If it is a simple small program, then why require private at all? 
It's small enough that knowing what all the code does by a single 
person is reasonable, let alone that it doesnt do anything 
complicated either.


On a side note, "function" is a keyword in D. Not sure if that 
was an intentional choice or not, but seems odd with your 
examples and the syntax highlighting.
Oct 26 2018
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 October 2018 at 02:07:56 UTC, luckoverthere wrote:

 On a side note, "function" is a keyword in D. Not sure if that 
 was an intentional choice or not, but seems odd with your 
 examples and the syntax highlighting.


That was an unintentional mistake I made.
Regardless this is nowhere near the final draft, as I have to 
take account of templates and string mixins. Which is not going 
to be trivial. My general philosophy is that if you only use 
module a for module b then use module scoping.
Same rational for local functions.
Oct 26 2018
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 October 2018 at 02:07:56 UTC, luckoverthere wrote:


 Why do "one time scripts" need this feature?


To avoid writing multiple files.



 D is less restrictive than C++, because it is less restrictive 
 you don't need to refactor. There also is no equivalent 
 "friend" feature in D. Since you are just copying and pasting 
 code, for the most part, where are you going to accidentally 
 call a private function you weren't calling before in C++ that 
 you are now going to call in D.


It does not necessarily involve friend functions. If your c++ 
code rely on the class is a unit of encapsulation as part of your 
design, then switching to d breaks that design as the module 
itself is the unit of encapsulation. You have to refactor your 
code by putting each class in its own file.


 Rapidly creating a program that involves multiple modules 
 requires multiple files for it, which can cause the slow down 
 the coding process, most noticeably in coding competition.





 Why would you be worried about encapsulation in a coding 
 competition, most likely the fastest code aren't going to be 
 following any sort of best practice as the fastest code will 
 probably be using some crazy hacks anyways.


That is more of a a broad objection to encapsulation in coding 
competition then the feature presented at the dip itself.


 If it is a simple small program, then why require private at 
 all?


That the design that the programmer decides on.
Oct 26 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sat, 27 Oct 2018 04:13:40 +0000, 12345swordy wrote:

 On Saturday, 27 October 2018 at 02:07:56 UTC, luckoverthere wrote:

 Why do "one time scripts" need this feature?


 To avoid writing multiple files.


Why do one-time scripts need extra tools to help maintainability? A one-
time script is not maintained by definition.

Is it that great a hardship to include multiple files when it's getting 
hard to maintain your project as a single file?


 It does not necessarily involve friend functions. If your c++ code rely
 on the class is a unit of encapsulation as part of your design, then
 switching to d breaks that design as the module itself is the unit of
 encapsulation. You have to refactor your code by putting each class in
 its own file.


If you wish to port a project from C++ to D, you should expect to have to 
refactor it after if you want a maintainable codebase. That's not 
surprising in the slightest.


 If it is a simple small program, then why require private at all?


 That the design that the programmer decides on.


So the motivation for choosing this sort of design is...because you chose 
this sort of design? Like, you decided on a constraint that your entire 
program had to fit in one file, and you find it difficult to maintain your 
program as one file because the unit of encapsulation doesn't match your 
design, but you made a decision, and by Aten you're sticking with it.
Oct 26 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 October 2018 at 04:54:30 UTC, Neia Neutuladh 
wrote:


 Why do one-time scripts need extra tools to help 
 maintainability? A one- time script is not maintained by 
 definition.


I have wrote scripts before with encapsulation in mind, because 
it consider to be good programming practice. Even that script is 
onetime use. It good to reuse code from old code such as scripts 
for example.


 Is it that great a hardship to include multiple files when it's 
 getting hard to maintain your project as a single file?


Ease of use comes to play here. If I had to create every file 
every time to ensure encapsulation in other languages I would go 
mad.


 If you wish to port a project from C++ to D, you should expect 
 to have to refactor it after if you want a maintainable 
 codebase. That's not surprising in the slightest.


You shouldn't have to refactor during porting process in order to 
ensure encapsulation. This feature minimize the refactoring.


 If it is a simple small program, then why require private at 
 all?


 That the design that the programmer decides on.


 So the motivation for choosing this sort of design is...because 
 you chose this sort of design?


I can't explain every design decision that you find it 
questionable. That is not the goal of the DIP here. You just have 
to trust the programmer judgement.
Oct 27 2018
next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sat, 27 Oct 2018 13:35:05 +0000, 12345swordy wrote:

 On Saturday, 27 October 2018 at 04:54:30 UTC, Neia Neutuladh wrote:

 Why do one-time scripts need extra tools to help maintainability? A
 one- time script is not maintained by definition.


 I have wrote scripts before with encapsulation in mind, because it
 consider to be good programming practice. Even that script is onetime
 use. It good to reuse code from old code such as scripts for example.


If you're reusing code, wouldn't you tend to pull it out into a library? 
You can use `dub build --single` to build a single-file dub package, using 
a comment in lieu of dub.sdl, and you can use `dub add-local` to expose 
that utility library on your local system.


 Is it that great a hardship to include multiple files when it's getting
 hard to maintain your project as a single file?


 
 Ease of use comes to play here. If I had to create every file every time
 to ensure encapsulation in other languages I would go mad.


So using Java, the most popular programming language in the world, would 
cause you to go mad?

I think that might indicate that D isn't the problem.


 If you wish to port a project from C++ to D, you should expect to have
 to refactor it after if you want a maintainable codebase. That's not
 surprising in the slightest.


 
 You shouldn't have to refactor during porting process in order to ensure
 encapsulation. This feature minimize the refactoring.


On the other hand, if you're porting from Java, D's encapsulation fits 
better.

D's encapsulation can't model C++'s exactly. This goes to how you decide 
how to arrange your source code into files, and C++ is much freer about 
this than almost any other language. But for some simple cases, it would 
ease porting.


 If it is a simple small program, then why require private at all?


 That the design that the programmer decides on.


 So the motivation for choosing this sort of design is...because you
 chose this sort of design?


 I can't explain every design decision that you find it questionable.
 That is not the goal of the DIP here. You just have to trust the
 programmer judgement.


DIPs are an area where we don't trust the judgment of the person making 
the proposal. We need an actual argument instead.

A good argument here would be a single D module which is complex enough 
that encapsulation is necessary and where it's apparent *why* it can't just 
be broken up into smaller modules.
Oct 27 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 October 2018 at 15:13:11 UTC, Neia Neutuladh 
wrote:

 DIPs are an area where we don't trust the judgment of the 
 person making the proposal. We need an actual argument instead.
 A good argument here would be a single D module which is 
 complex enough that encapsulation is necessary and where it's 
 apparent *why* it can't just be broken up into smaller modules.


I had simplify the DIP rationale as it quite apparent that people 
are missing the forest for the trees by nitpicking the design 
choice that hypothetical programmer may use in the examples 
rather then focusing the underlying "one file per module" 
restriction.

-Alex
Oct 27 2018
parent reply luckoverthere <luckoverthere gmail.cm> writes:
On Saturday, 27 October 2018 at 15:25:10 UTC, 12345swordy wrote:

 On Saturday, 27 October 2018 at 15:13:11 UTC, Neia Neutuladh 
 wrote:

 DIPs are an area where we don't trust the judgment of the 
 person making the proposal. We need an actual argument instead.
 A good argument here would be a single D module which is 
 complex enough that encapsulation is necessary and where it's 
 apparent *why* it can't just be broken up into smaller modules.


 I had simplify the DIP rationale as it quite apparent that 
 people are missing the forest for the trees by nitpicking the 
 design choice that hypothetical programmer may use in the 
 examples rather then focusing the underlying "one file per 
 module" restriction.

 -Alex


The way it is implemented is promoting even poorer practices.


 void function()
 {
   module A
   {
     ...
   } }

 Which is equalivent to:
 
 void function()
 {
   import A;
 }


Why would you want to define a module within a function? What 
benefit does this provide over what you can already do? Who else 
is even going to be able to access this module? If no one else 
can access it there's no point in it being a module.

Not even C++ makes this mistake of allowing namespaces in the 
body of functions. Same thing goes for modules being defined in 
classes.

Just cause you can import a module in these places, does not mean 
you should be able to define an entire module in the same place.
Oct 28 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 28 October 2018 at 12:32:57 UTC, luckoverthere wrote:

 The way it is implemented is promoting even poorer practices.


 void function()
 {
   module A
   {
     ...
   } }

 Which is equalivent to:
 
 void function()
 {
   import A;
 }


 Why would you want to define a module within a function?


Not allowing it, will result the "if you can import it you can 
build it" rule being inconsistent. It no different then creating 
a separate file that is only called by one function from another 
file.

 What benefit does this provide over what you can already do?


Lots surprisingly. Don't worry, I will address the benefits that 
arise from this in the dip in the future.

 Who else is even going to be able to access this module?


The same reason for nested functions and nested classes, no one, 
that is the whole point! If you want it to be shared then don't 
put it there in the first place.

 If no one else can access it there's no point in it being a 
 module.


You can argue against nested function and nested class using that 
logic!


 Not even C++ makes this mistake of allowing namespaces in the 
 body of functions!


No one wants c++ namespaces here, as we have modules!

 Same thing goes for modules being defined in classes.


We already allow nested functions and nested classes, why not 
nested modules as well?

 Just cause you can import a module in these places, does not 
 mean you should be able to define an entire module in the same 
 place.


Nonsense, D pride itself as a practical language. That is why D 
have gotos, which if you don't like it, don't use it!
Oct 28 2018
parent reply luckoverthere <luckoverthere gmail.cm> writes:
On Sunday, 28 October 2018 at 16:16:01 UTC, 12345swordy wrote:

 On Sunday, 28 October 2018 at 12:32:57 UTC, luckoverthere wrote:

 The way it is implemented is promoting even poorer practices.


 void function()
 {
   module A
   {
     ...
   } }

 Which is equalivent to:
 
 void function()
 {
   import A;
 }


 Why would you want to define a module within a function?


 Not allowing it, will result the "if you can import it you can 
 build it" rule being inconsistent. It no different then 
 creating a separate file that is only called by one function 
 from another file.


Probably for the better, importing with classes and functions is 
actually useful. Being able to define a module in those scopes 
provides nothing.


 What benefit does this provide over what you can already do?


 Lots surprisingly. Don't worry, I will address the benefits 
 that arise from this in the dip in the future.


Ok, why not give some now?


 Who else is even going to be able to access this module?


 The same reason for nested functions and nested classes, no 
 one, that is the whole point! If you want it to be shared then 
 don't put it there in the first place.


Yes that's the point, which benefits classes and functions, but 
the point of a module is provide a grouping. If that grouping is 
inaccessible to anyone else then there really isn't any benefit. 
The class and function act as a grouping in this case.


 If no one else can access it there's no point in it being a 
 module.


 You can argue against nested function and nested class using 
 that logic!


Having nested functions and classes is useful though. Having a 
nested module within a pseudo module (the class/function) isn't 
really beneficial.


 Not even C++ makes this mistake of allowing namespaces in the 
 body of functions!


 No one wants c++ namespaces here, as we have modules!


Missing the point, even C++ with all its warts is smart enough 
not to implement nested namespaces in classes and functions 
(namespaces being C++'s way of grouping code vs D's modules).


 Same thing goes for modules being defined in classes.


 We already allow nested functions and nested classes, why not 
 nested modules as well?


Because they provide little benefit, the functional purpose of a 
module is to group classes and functions. Nested classes and 
functions already have a grouping, the class/function they are 
nested in. We don't need further groupings in these cases.


 Just cause you can import a module in these places, does not 
 mean you should be able to define an entire module in the same 
 place.


 Nonsense, D pride itself as a practical language. That is why D 
 have gotos, which if you don't like it, don't use it!


You keep bringing up gotos, but aside from that rule you seem to 
like to follow. Gotos actually have their uses. Nested modules do 
not. Over filling a language with features also isn't a good 
thing and makes is less practical as a whole. Having too many 
features, especially ones that add little value just complicates 
the language. Making it harder to read and write for everyone. 
Not just the people that choose to use one of the features 
everyone else avoids.
Oct 28 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 28 October 2018 at 23:47:21 UTC, luckoverthere wrote:


 Probably for the better, importing with classes and functions 
 is actually useful. Being able to define a module in those 
 scopes provides nothing.


No, it provides encapsulation. It no different the defining it in 
another file and only use it at that particular function/class.



 Ok, why not give some now?


Look up the limitations of nested functions.


 Yes that's the point, which benefits classes and functions, but 
 the point of a module is provide a grouping.


Modules are the unit of encapsulation. It does not solely exist 
for grouping.


 If that grouping is inaccessible to anyone else then there 
 really isn't any benefit.
 The class and function act as a grouping in this case.
 Having nested functions and classes is useful though.


You are contradicting yourself here. Nested class/functions are 
inaccessible to anyone else. Ergo they aren't really benefit to 
them according to your logic.



 Missing the point, even C++ with all its warts is smart enough 
 not to implement nested namespaces in classes and functions 
 (namespaces being C++'s way of grouping code vs D's modules).


C++ namespaces and D modules are not remotely the same thing.
https://stackoverflow.com/questions/6326805/why-using-namespace-x-is-not-allowed-inside-class-struct-level


 Because they provide little benefit, the functional purpose of 
 a module is to group classes and functions.


Modules are the unit of encapsulation. It does not solely exist 
for grouping.


 Nested modules do not.


Creating classes and putting them in their own modules in the 
same file under the same package isn't a benefit!?
The nested module exist to get rid of one module per file 
restriction and to provide easy encapsulation.

Regardless you not the person that the DIP need to be convinced. 
It's andrei and walter.
Oct 28 2018
next sibling parent reply luckoverthere <luckoverthere gmail.cm> writes:
On Monday, 29 October 2018 at 00:45:47 UTC, 12345swordy wrote:

 On Sunday, 28 October 2018 at 23:47:21 UTC, luckoverthere wrote:


 Probably for the better, importing with classes and functions 
 is actually useful. Being able to define a module in those 
 scopes provides nothing.


 No, it provides encapsulation. It no different the defining it 
 in another file and only use it at that particular 
 function/class.


How is encapsulation going to be beneficial in a situation where 
the class can only be used from inside that function?



 Ok, why not give some now?


 Look up the limitations of nested functions.


That wasn't the question. If you don't have an answer then that's 
fine, say you don't though.


 Yes that's the point, which benefits classes and functions, 
 but the point of a module is provide a grouping.


 Modules are the unit of encapsulation. It does not solely exist 
 for grouping.


In this case the function/class is the unit of encapsulation, you 
can't access nested functions/class unless they are returned.


 If that grouping is inaccessible to anyone else then there 
 really isn't any benefit.
 The class and function act as a grouping in this case.
 Having nested functions and classes is useful though.


 You are contradicting yourself here. Nested class/functions are 
 inaccessible to anyone else. Ergo they aren't really benefit to 
 them according to your logic.


That's the point of them, they aren't accessible to anyone, 
that's the encapsulation. They can still be returned as well if 
wanted. You would be adding a grouping on top of a grouping. The 
function grouping is much more restrictive than a module 
grouping, not even other functions in same module can access 
nested functions/classes (unless it is used as the returning 
type).


 Missing the point, even C++ with all its warts is smart enough 
 not to implement nested namespaces in classes and functions 
 (namespaces being C++'s way of grouping code vs D's modules).


 C++ namespaces and D modules are not remotely the same thing.
 https://stackoverflow.com/questions/6326805/why-using-namespace-x-is-not-allowed-inside-class-struct-level


Lol you had to google that and it's a link to a stackoverflow 
question no less.

They serve the same purpose, to group code and provide a means to 
avoid name collisions between differing objects. They can also be 
used to ensure functions are encapsulated to a specific source 
unit using anonymous namespaces.

You can also research C++ proposal for modules, which is 
implement in a similar fashion to what you are suggestion. 
Allowing multiple modules in one file. Their implementation 
however, does not allow modules to be defined in a function or 
class.


 Because they provide little benefit, the functional purpose of 
 a module is to group classes and functions.


 Modules are the unit of encapsulation. It does not solely exist 
 for grouping.


And you already have that encapsulation because it is nested. In 
this case the function and class are the units of encapsulation.


 Nested modules do not.


 Creating classes and putting them in their own modules in the 
 same file under the same package isn't a benefit!?
 The nested module exist to get rid of one module per file 
 restriction and to provide easy encapsulation.


Seems your misunderstanding here, nested modules, as in nested in 
a function/class.


 Regardless you not the person that the DIP need to be 
 convinced. It's andrei and walter.


Your right, it'll be much harder to convince andrei and walter 
than it would be to convince me.
Oct 28 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 29 October 2018 at 01:17:06 UTC, luckoverthere wrote:

 How is encapsulation going to be beneficial in a situation 
 where the class can only be used from inside that function?


That because, nested classes are NOT encapsulated in the function!
The module itself is the encapsulation unit, not the class. (I 
learn that the hard way)

int func()
{
     class Inner
     {
         private int x;
     }
     Inner ex = new Inner();
     ex.x = 1;
    globalvar = ex.x;
    return ex.x;
}

This compiles btw.


 That wasn't the question.


You ask "what are the benefits", I had give you the answer: The 
Dip will address the limitations of nested functions and provide 
a solution for them via nested modules.


 In this case the function/class is the unit of encapsulation


No, they are NOT! The module IS unit of encapsulation. Period. 
Global variables can accessing anything provided that they are in 
the same module.


 That's the point of them, they aren't accessible to anyone, 
 that's the encapsulation.


If they are in the same module, yes you can! If you try to create 
a global pointer outside the function that points to local 
private variable inside the function in the same module you are 
technically accessing it! You just got a dangling pointer after 
the function is called.


 Lol you had to google that and it's a link to a stackoverflow 
 question no less.


You are creating a false equivalence by comparing D modules with 
C++ namespace.
You can import modules in a class in D, you can't import a 
namespace in class in C++. Ergo your comparison fall flat.


 Their implementation however, does not allow modules to be 
 defined in a function or class.


Irrelevant.


 And you already have that encapsulation because it is nested.


Nested classes/functions are not encapsulated. The module itself 
is the unit of encapsulation.



 Seems your misunderstanding here, nested modules, as in nested 
 in a function/class.


Nested classes/functions are not encapsulated. The module itself 
is the unit of encapsulation.


 Your right, it'll be much harder to convince andrei and walter 
 than it would be to convince me.


It seems that way if you oppose it on ideological grounds.
Regardless, apparently I need to dedicate a section that is 
called "Only the module itself is the unit of encapsulation" in 
the DIP.
Oct 29 2018
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 29 October 2018 at 14:45:19 UTC, 12345swordy wrote:

 On Monday, 29 October 2018 at 01:17:06 UTC, luckoverthere wrote:



 int func()
 {
     class Inner
     {
         private int x;
     }
     Inner ex = new Inner();
     ex.x = 1;
    globalvar = ex.x;
    return ex.x;
 }

 This compiles btw.


So? You, the programmer, are breaking encapsulation here by 
accessing 'private' member. You wrote that code, you better know 
what 'x' is. Your argument seems to be based on an assumption 
that you don't have to know. But you do, otherwise you shouldn't 
be writing code.


 That wasn't the question.


 You ask "what are the benefits", I had give you the answer: The 
 Dip will address the limitations of nested functions and 
 provide a solution for them via nested modules.


That'd be interesting to see. Why didn't you put those supposed 
limitations in there to begin with? I.e. what's the purpose of 
this "messy draft"?


 In this case the function/class is the unit of encapsulation


 No, they are NOT! The module IS unit of encapsulation. Period. 
 Global variables can accessing anything provided that they are 
 in the same module.


Global variables aren't accessing anything. You (the programmer) 
are, by assigning values to them.


 That's the point of them, they aren't accessible to anyone, 
 that's the encapsulation.


 If they are in the same module, yes you can! If you try to 
 create a global pointer outside the function that points to 
 local private variable inside the function in the same module 
 you are technically accessing it! You just got a dangling 
 pointer after the function is called.


That's not an issue with encapsulation at all. That's a lifetime 
issue.

```
int* global;

void main()  safe {
     int x;
     global = &x;
}

$ dmd -dip1000 test.d
test.d(5): Error: address of variable x assigned to global with 
longer lifetime
```


 Nested classes/functions are not encapsulated. The module 
 itself is the unit of encapsulation.


You're confusing encapsulation and scopes now:

void main() {
     void bar() {}
}

void foo() {
     main.bar(); // Error: no property bar for type void
}
Oct 29 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 29 October 2018 at 15:00:07 UTC, Stanislav Blinov 
wrote:


 So? You, the programmer, are breaking encapsulation here by 
 accessing 'private' member.


There is no encapsulation break, as it located in the same 
module. The encapsulation that you speak of is human enforced.


 That'd be interesting to see. Why didn't you put those supposed 
 limitations in there to begin with? I.e. what's the purpose of 
 this "messy draft"?


To get feedback. Which allows me to spot things that need 
revisiting or need better explaining. This isn't the final draft. 
Not by a long shot.



 Global variables aren't accessing anything. You (the 
 programmer) are, by assigning values to them.


That counter point doesn't make any sense. You act like that I am 
arguing that they are intelligent or something.



 That's not an issue with encapsulation at all. That's a 
 lifetime issue.


Not my point. The point is that the compiler won't complain that 
you are getting the local variable in the function from outside 
the function, irregardless that you set it to private or not and 
will compile just as fine.



 Nested classes/functions are not encapsulated. The module 
 itself is the unit of encapsulation.


 You're confusing encapsulation and scopes now:


*shrugs*
  The other user treat them as one as the same.
Oct 29 2018
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 29 October 2018 at 15:50:33 UTC, 12345swordy wrote:

 On Monday, 29 October 2018 at 15:00:07 UTC, Stanislav Blinov 
 wrote:


 So? You, the programmer, are breaking encapsulation here by 
 accessing 'private' member.


 There is no encapsulation break, as it located in the same 
 module. The encapsulation that you speak of is human enforced.


Again, so?..
If I saw such code in C++, I'd known that it either won't 
compile, or I'd need to check if I'm in a friend code.
If I saw such code in D, my first thought would be that the 
author did that intentionally. Because *that's what D's 
'private'* is intended for.

This is quite common pattern in D:

--- list.d

struct List(T) {
     private struct Node { /* ... */ }
     private Node* head;
}

auto makeList(R)(R range) {
     import std.range;
     alias T = ElementType!R;
     alias Node = List!T.Node; // oh no, that'd break 
"encapsulation" in C++
     Node* head;
     foreach_reverse (e; range) {
         auto n = new Node(e);
         n.next = head;
         head = n;
     }
     return List!T(head);
}

--- main.d

void main() {
     auto list = [ 1, 2, 3, 4 ].makeList;
     /* ... */
}

And this doesn't just apply to lists. It becomes *very* easy to 
make complex implementations without putting in made-up 
roadblocks for yourself, or jumping through hoops to "white-list" 
friends. That is what D's 'private' for. For everything else, 
there are packages. Now, if that's not enough for you, then you 
need to show, quite clearly, *why* that is.


 That'd be interesting to see. Why didn't you put those 
 supposed limitations in there to begin with? I.e. what's the 
 purpose of this "messy draft"?


 To get feedback. Which allows me to spot things that need 
 revisiting or need better explaining. This isn't the final 
 draft. Not by a long shot.


Then why are you arguing? Wouldn't it be more productive to 
analyze the feedback and update the document as you see fit? So 
far you didn't present any practical use case for your proposal, 
other than some arguable "good practice", people are saying as 
much.


 Global variables aren't accessing anything. You (the 
 programmer) are, by assigning values to them.


 That counter point doesn't make any sense. You act like that I 
 am arguing that they are intelligent or something.


No, you're arguing that having globals somehow breaks 
"encapsulation" of *other* data. It doesn't, not unless the 
programmer says so. Copying a *value* from a private member to 
another variable isn't breaking any encapsulation at all. You 
literally do that all the time when implementing your beloved 
getters.


 That's not an issue with encapsulation at all. That's a 
 lifetime issue.


 Not my point. The point is that the compiler won't complain 
 that you are getting the local variable in the function from 
 outside the function, irregardless that you set it to private 
 or not and will compile just as fine.


The compiler does complain for cases when it should, as I've 
shown in the example that you cut out. You're not getting 
anything from outside the function, you pass it over from within.


 Nested classes/functions are not encapsulated. The module 
 itself is the unit of encapsulation.


 You're confusing encapsulation and scopes now:


 *shrugs*
  The other user treat them as one as the same.


And?..
Oct 29 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 29 October 2018 at 16:31:31 UTC, Stanislav Blinov 
wrote:


 Then why are you arguing? Wouldn't it be more productive to 
 analyze the feedback and update the document as you see fit? So 
 far you didn't present any practical use case for your 
 proposal, other than some arguable "good practice", people are 
 saying as much.


That a really good question, bad habit I suppose?


 And?..


Why did you specifically call me out then?
Oct 29 2018
parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 29 October 2018 at 16:40:43 UTC, 12345swordy wrote:


 And?..


 Why did you specifically call me out then?


Because it's your thread and your DIP, so you at least should get 
your definitions straight, and clearly communicated.
Oct 29 2018
prev sibling parent reply luckoverthere <luckoverthere gmail.cm> writes:
// A.d /////////////////////////////////////////////////////////

module A;

public import A.B; // What happens here now ?

module B
{
    void foo();
}

// B.d ////////////////////////////////////////////////////////

module A.B;

void foo();

//////////////////////////////////////////////////////


Then consider code like this, which will compile fine, using the 
file with module A.B

import A.B;

A.B.foo();


But then when if you decide to change it and import A instead:


import A;

A.B.foo();


You are calling a different function from the same module name. 
As there are actually two difference instances of the module, 
module A.B can mean two different things depending on the 
circumstance.
Oct 28 2018
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 29 October 2018 at 01:37:07 UTC, luckoverthere wrote:

 // A.d /////////////////////////////////////////////////////////

 module A;

 public import A.B; // What happens here now ?

 module B
 {
    void foo();
 }


what you are doing is the equivalent of this:

module A.B;
public import A.B;



 You are calling a different function from the same module name.


If you have more then one module with the same name with 
conflicting definitions then the compiler will give you an 
ambiguity error. You can encounter that same problem without this 
Dip. Put two modules named A in the same folder with different 
functions definitions and try to call it from module B.

-Alex
Oct 29 2018
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 27 October 2018 at 15:13:11 UTC, Neia Neutuladh 
wrote:

 So using Java, the most popular programming language in the 
 world, would cause you to go mad?


I am actually working on some Java right now and it totally 
drives me nuts. The directory structures are so deep and there 
are so many little files.

I finally have a handle on what it is doing though, yay!



As to this DIP, meh, I could quibble with the specifics, but I 
have kinda wanted multiple modules per file before myself, though 
it isn't a big deal (indeed, library packaging is another 
alternative). It just seems like an arbitrary limitation not to 
allow another module declaration there. In C, you can cat *.c > 
combined.c and still build it (well, generally), but in D that 
always creates errors.

Multiple smaller modules do the encapsulation and can help with 
code bloat, though compiler implementation improvements are 
helping with that too. But recall that is why the package.d thing 
was added.

Again, no big deal, but I could see myself sometimes using it.
Oct 27 2018
prev sibling parent reply Jusl <jusl gmail.usa> writes:
On Saturday, 27 October 2018 at 13:35:05 UTC, 12345swordy wrote:

 On Saturday, 27 October 2018 at 04:54:30 UTC, Neia Neutuladh 
 wrote:


 Why do one-time scripts need extra tools to help 
 maintainability? A one- time script is not maintained by 
 definition.


 I have wrote scripts before with encapsulation in mind, because 
 it consider to be good programming practice. Even that script 
 is onetime use. It good to reuse code from old code such as 
 scripts for example.


So when you copy and paste, do so by putting it into its own 
module. If you are just going to copy and paste it into another 
one time script then it doesn't really make a whole lot of sense. 
You can still use private and such in your one time script and 
when you copy and paste it to a larger file with its own modules 
you will have the encapsulation.

Separating code into multiple files with modules is also good 
programming practice :). If you are going to day that you can't 
really pick and choose the ones that only benefit your argument.
Oct 27 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 October 2018 at 20:34:36 UTC, Jusl wrote:

 So when you copy and paste, do so by putting it into its own 
 module.


...Which you be doing anyways with the feature I presented.
Don't like it? Don't use it. Same reason for goto statements.

 If you are just going to copy and paste it into another one 
 time script then it doesn't really make a whole lot of sense.


Which is your opinion. I have use old code from one time scripts 
before, and saves me quite amount of time. No need to write 
multiple files to write a one time script that involves 
encapsulation. Which again a design decision that I and other 
programmers can make. People are going to use d language in ways 
that you may not agree with. You not agreeing with the design 
decision they make is not an argument against the features 
themselves.

 You can still use private and such in your one time script and 
 when you copy and paste it to a larger file with its own 
 modules you will have the encapsulation.


Again a mere opinion regarding design decision and not the 
feature itself.

 Separating code into multiple files with modules is also good 
 programming practice :).


Which sometimes you got break the rules in order to get something 
done. Like using goto for instance.

 If you are going to day that you can't really pick and choose 
 the ones that only benefit your argument.


...What?
Oct 27 2018
next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sat, 27 Oct 2018 22:03:12 +0000, 12345swordy wrote:

 Which is your opinion. I have use old code from one time scripts before,
 and saves me quite amount of time. No need to write multiple files to
 write a one time script that involves encapsulation.


This sounds like the perfect use case for a personal utility library.
Oct 27 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 October 2018 at 22:51:15 UTC, Neia Neutuladh 
wrote:

 This sounds like the perfect use case for a personal utility 
 library.


I consider that solution to be over engineering to me. Regardless 

D.

Again it seems like people are missing the forest for the trees 
by focusing on the examples themselves rather then the underline 
argument that there are reasonable possible situations that the 
programmer find it easier to create file to that stores multiple 
modules then to create every file for every module.

-Alex
Oct 27 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Sat, 27 Oct 2018 23:17:36 +0000, 12345swordy wrote:

 On Saturday, 27 October 2018 at 22:51:15 UTC, Neia Neutuladh wrote:

 This sounds like the perfect use case for a personal utility library.


 I consider that solution to be over engineering to me. Regardless I was

 
 Again it seems like people are missing the forest for the trees by
 focusing on the examples themselves rather then the underline argument
 that there are reasonable possible situations that the programmer find
 it easier to create file to that stores multiple modules then to create
 every file for every module.


You have a tool in mind to address a narrow set of circumstances. It would 
be useful. But we do already have tools to address the same circumstances. 
Not quite as well, but they're already here. And D is already a very 
complex language with a lot for people to learn, so any new changes have to 
be pretty valuable to be justified.

The way we justify changes is by looking at examples to see what existing 
features don't allow or only allow awkwardly, and then comparing with how 
the proposed change would make them work.
Oct 27 2018
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 28 October 2018 at 00:14:05 UTC, Neia Neutuladh wrote:

 On Sat, 27 Oct 2018 23:17:36 +0000, 12345swordy wrote:

 [...]


 You have a tool in mind to address a narrow set of 
 circumstances. It would be useful. But we do already have tools 
 to address the same circumstances. Not quite as well, but 
 they're already here. And D is already a very complex language 
 with a lot for people to learn, so any new changes have to be 
 pretty valuable to be justified.

 The way we justify changes is by looking at examples to see 
 what existing features don't allow or only allow awkwardly, and 
 then comparing with how the proposed change would make them 
 work.


Yup. I noticed that I didn't clarify in regards to the public 
import and plan old import, I need to fix that.
Oct 28 2018
prev sibling parent reply luckoverthere <luckoverthere gmail.cm> writes:
On Saturday, 27 October 2018 at 22:03:12 UTC, 12345swordy wrote:

 Separating code into multiple files with modules is also good 
 programming practice :).


 Which sometimes you got break the rules in order to get 
 something done. Like using goto for instance.


You could say the same thing about your one time scripts. You can 
break your rule of encapsulation being a good programming 
practice in order to get your one time script done (into one 
file). Like these rules don't need to be followed to the letter, 
nor should they be. Encapsulation provides benefits for projects 
of larger scale, where it is unrealistically possible for someone 
to know how everything operates, or spending the time to figure 
out how it works. This benefit does not really extend to one time 
scripts. If your scripts are getting so large that it does 
benefit, then they probably shouldn't be one file any longer.

You can try and argue in the DIP that having a single extra-large 
file is good practice and is something D should support, but 
that's honestly an argument you are probably going to fail to 
convince anyone of.

Now you have to consider the complicated situation you are now 
able to achieve with your new system.

How do you handle multiple modules with the same name. You 
mention that this is the same:

module A;

public import B;

is the same as:

module A;

module B
{
     void foo();
}

So that means B is not part of A, correct? So if I do:

import A;

B.foo(); // I can access B without going through A
foo();   // same here

What happens now when you have a separate module with B ?


import A;
import B;


Does the module B in A work with just the separate module B?

Or even worse:

module C;

module B
{
     void foo();
}

///////////////////////////

import A;
import B;
import C;

B.foo(); // Which does this call now ?


These are details you are going to have to iron our, and 
depending on how you want to implement it, will cause the 
implementation for the compiler to become extremely complicated 
(as which is the case with C++ namespaces).
Oct 28 2018
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 28 October 2018 at 12:50:30 UTC, luckoverthere wrote:

 On Saturday, 27 October 2018 at 22:03:12 UTC, 12345swordy wrote:

 Separating code into multiple files with modules is also good 
 programming practice :).


 Which sometimes you got break the rules in order to get 
 something done. Like using goto for instance.


 You could say the same thing about your one time scripts. You 
 can break your rule of encapsulation being a good programming 
 practice in order to get your one time script done (into one 
 file). Like these rules don't need to be followed to the 
 letter, nor should they be.


Yet, you have no tools to write multiple modules in a file in D. 
It not a rule but a hard limitation.

 This benefit does not really extend to one time scripts.


That itself is very opinionated and debatable, and the dip itself 
is not about specifically one-time scripts. People keep focusing 
on the tree rather then the overall forest, so I had remove that 
section and plan to do over again by focusing on the one file per 
module limitation and how that should it be a rule of thumb 
rather then a hard limitation.

 If your scripts are getting so large that it does benefit, then 
 they probably shouldn't be one file any longer.


Again debatable, not reason why the DIP exist.


 You can try and argue in the DIP that having a single 
 extra-large file is good practice and is something D should 
 support, but that's honestly an argument you are probably going 
 to fail to convince anyone of.


Which I am not arguing. I am arguing to allow creation of 
multiple modules in single file.

 Now you have to consider the complicated situation you are now 
 able to achieve with your new system.

 How do you handle multiple modules with the same name. You 
 mention that this is the same:

 module A;

 public import B;

 is the same as:

 module A;

 module B
 {
     void foo();
 }

 So that means B is not part of A, correct?


No, that is NOT equivalent!

module A;

public import A.B; //This is where you got it wrong.

is the same as:

module A;

module B //This is viewed as A.B or module B part of package A
{
    void foo();
}

 I can access B without going through A




No you can't. Module B is part of the A package.


 Does the module B in A work with just the separate module B?


Yes, because module B is part of the A package. So it just really 
A.B and B which are completely different.



 module C;

 module B
 {
     void foo();
 }

 ///////////////////////////

 import A;
 import B;
 import C;

 B.foo(); // Which does this call now ?


C.B.foo(); // calls C package
B.foo(): // calls B module

Otherwise the compiler will throw a ambiguity error.
Oct 28 2018
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 28 October 2018 at 12:50:30 UTC, luckoverthere wrote:

 You can try and argue in the DIP that having a single 
 extra-large file is good practice and is something D should 
 support, but that's honestly an argument you are probably going 
 to fail to convince anyone of.



Also don't give out suggestions that you think are futile. That 
is just being condescending.
Oct 28 2018
parent luckoverthere <luckoverthere gmail.cm> writes:
On Sunday, 28 October 2018 at 17:50:14 UTC, 12345swordy wrote:

 On Sunday, 28 October 2018 at 12:50:30 UTC, luckoverthere wrote:

 You can try and argue in the DIP that having a single 
 extra-large file is good practice and is something D should 
 support, but that's honestly an argument you are probably 
 going to fail to convince anyone of.



 Also don't give out suggestions that you think are futile. That 
 is just being condescending.


I wasn't giving it as a suggestion, you already had added that 
bit to your DIP, though you didn't really expand on it. And I was 
merely giving my opinion of it. It's a good thing you removed it.
Oct 28 2018
prev sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Saturday, 27 October 2018 at 00:20:33 UTC, 12345swordy wrote:

 https://github.com/12345swordy/DIPs/blob/Encapsulation/DIPs/DIPxxxx.md
 Yea, yea, I know it format wise it a giant mess, but I got 
 start somewhere don't I?


Ok I have simply rationale by stating that one module per file 
should be a guideline/rule of thumb rather then a hard limit. 
There are cases/situations where it easier to put multiple 
modules in a single file.
Oct 27 2018