On Sunday, 13 May 2018 at 17:19:26 UTC, rumbu wrote:
> On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote:
>
>> Also, someone may say: I can see what happens in one and the same file. If there are two classes/structs in one file, they are "friends" and I dont need the "friend"-keyword anymore.
>> Thats an argument, too.
>
> So, when you have 1000 classes, you just create 1000 files just to "unfriend" them :)

If you have 1000 classes in a single module, you have bigger problems than encapsulation. :p

--
  Simen

On Saturday, 12 May 2018 at 15:48:53 UTC, KingJoffrey wrote:
> On Saturday, 12 May 2018 at 13:38:18 UTC, Walter Bright wrote:
>>
>> Mike's right. D's encapsulation model is designed around the module.
>
> Actually, that is not true. If it were true, then I could do:
>
> ------------
> module test;
> void main() { i = 2; }  // sorry, but i belongs to another unit of encapsulation
> void foo() { int i = 1; }
> ------------

No, it would be like:

------------
module test;
void main() { foo.i = 2; }
of encapsulation
void foo() { static int i = 1; }
------------

...and I think there might be point in allowing that.

Non-static members could also perhaps be accessed in case of fibers, but that would likely be tough to implement and/or complicate the runtime.

On Monday, 14 May 2018 at 07:02:37 UTC, Dukc wrote:

> ------------
> module test;
> void main() { foo.i = 2; }
> of encapsulation
> void foo() { static int i = 1; }
> ------------

meant

------------
module test;
void main() { foo.i = 2; }
void foo() { static int i = 1; }
------------

On Monday, 14 May 2018 at 07:03:35 UTC, Dukc wrote:
>
> ------------
> module test;
> void main() { foo.i = 2; }
> void foo() { static int i = 1; }
> ------------

nice, .. I like it... I mean who really needs a function interface anyway?

D may as well just get rid of that encapsulation concept too, since the class interface is pretty much moot in D modules.

Maybe.. we should even, just completely get rid of functions and classes - as well as all that other stupid so-called 'structured programming' crap, which just restricts us, and revert to 'real' programming - using just line numbers and goto statements. Then, finally, we programmers can do whatever we want again.

Local reasoning...it's so old-school.

On Monday, May 14, 2018 07:03:35 Dukc via Digitalmars-d wrote:
> On Monday, 14 May 2018 at 07:02:37 UTC, Dukc wrote:
> > ------------
> > module test;
> > void main() { foo.i = 2; }
> > of encapsulation
> > void foo() { static int i = 1; }
> > ------------
>
> meant
>
> ------------
> module test;
> void main() { foo.i = 2; }
> void foo() { static int i = 1; }
> ------------

If that's what you want, just make it a module-level variable. I don't think that providing access to symbols inside functions like that wouldn really buy us anything. In addition, we rely on function encapsulation for Voldemort types, and the rules for local variables and types are a bit special anyway. Trying to treat them as if they were at the module-level but namespaced by the function seems like it would be complicating things considerably for no real benefit.

- Jonathan M Davis

On Monday, 14 May 2018 at 07:59:06 UTC, Jonathan M Davis wrote:
> .. In addition, we rely on function encapsulation for Voldemort types...

Actually, we rely on encapsulation (boundaries) for a lot more than that.

How do we get from the orange room to the blue room, if there is no boundary?

https://www.youtube.com/watch?v=IP5akjPwqEA

(great quote at the end btw - but watch the whole thing first - it'll make more sense)

On Saturday, 12 May 2018 at 15:36:56 UTC, Walter Bright wrote:
> On 5/12/2018 8:18 AM, Piotr Mitana wrote:
>> What I am trying to do is:
>
>
> ========== a.d ============
>
> class P
> {
>     private this();
> }
>
> final class C1 : P { }
> final class C2 : P { }
>
> ======== test.d ============
>
> import a;
>
> void foo()
> {
>     P[] twoPs = [ new C1(), new C2() ]; // works
> }
>
> class C3 : P   // fails
> {
> }
>
> ============================
>
> dmd test a
> Error: constructor a.P.this is not accessible from module test

OK, Walter, point for you for this :)

I still think that this is a kind of a hack (if I need to create an instance of P directly, I need a factory method - it's also not that clean and obvious), but in fact it effectively seems to do what I want to achieve.

Although I consider sealed as a nice addition still to make things nice and clean, I understand that it may be not enough justified to add a new keyword to the language. Thank you for all the opinions on that. :)

On Monday, 14 May 2018 at 07:59:06 UTC, Jonathan M Davis wrote:
> On Monday, May 14, 2018 07:03:35 Dukc via Digitalmars-d wrote:
>> On Monday, 14 May 2018 at 07:02:37 UTC, Dukc wrote:
>> ------------
>> module test;
>> void main() { foo.i = 2; }
>> void foo() { static int i = 1; }
>> ------------
>
> If that's what you want, just make it a module-level variable.

Well, personally I don't care much because using static mutables sucks anyway, and there is rarely a reason to make static immutables just for one function. Enums are for that.

Just pointed out that it would be consistent with how classes encapsulate stuff. And the same point goes for eponymous templates, of course.

On Monday, 14 May 2018 at 07:44:00 UTC, KingJoffrey wrote:

> D may as well just get rid of that encapsulation concept too, since the class interface is pretty much moot in D modules.
>
> Maybe.. we should even, just completely get rid of functions and classes - as well as all that other stupid so-called 'structured programming' crap, which just restricts us, and revert to 'real' programming - using just line numbers and goto statements. Then, finally, we programmers can do whatever we want again.
>
> Local reasoning...it's so old-school.

A slippery slope fallacy isn't helping your case. Write a DIP if it bothers you so much, as it changes the languages fundamentally.


Alexander

On 5/14/2018 1:32 AM, Piotr Mitana wrote:
> OK, Walter, point for you for this :)

Welcs!