On Tuesday, 13 March 2018 at 06:43:55 UTC, ketmar wrote:
>
> that is, we should stick to defective design only 'cause there is no "other D" that made it right? ;-)
>
> also, your question is not valid. you were told several times that you're evaluating the whole thing wrong, but you're insisting on your view being right. and you're keep asking, omiting the *critical* piece of the picture: modules. you were told that in D, encapsulation unit is *module*, not class/struct. it is not a "misdesign", it is the proper modular design. it doesn't matter what others are doing in this case.
>
> p.s.: yes, i know such language. Delphi/FreePascal.

Gee.. I feel like I'm on a Rust forum, being attacked my their sjw moderators.

Whatever happened to the 'discussion' component of these 'discussions'?

Your thought model is much younger than modules. Modules have existed since the mid 70's.
They work, other designs over the years have proven to have faults and problems.

D's design is evolved from already existing ideas to try and give the best of both worlds and modules is no different.

The reality is, Java and C++ both are great examples where module system was added after many years too late. D had it built in from the get go and was designed to benefit from it.

On Tuesday, 13 March 2018 at 07:05:48 UTC, rikki cattermole wrote:
> Your thought model is much younger than modules. Modules have existed since the mid 70's.
> They work, other designs over the years have proven to have faults and problems.
>
> D's design is evolved from already existing ideas to try and give the best of both worlds and modules is no different.
>
> The reality is, Java and C++ both are great examples where module system was added after many years too late. D had it built in from the get go and was designed to benefit from it.

I don't have any objection to the idea that a module can have privileged access to members of classes within that model. It sounds sensible enough, if the module is a level of encapsulation also.

My arguments is that, this was implemented in D, at the cost of removing the capacity for a class in the same module to protect it's own members (within the module). That's what I don't like about it.

My other objection, as stated, is that D uses the same syntax as C++/C#/Java, but the semantics of that same syntax are completely different. I also don't like that.

On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
>
> I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module".
>

what about a new access attribute (and no, I haven't though this through much):

owned string _FirstName;

(now the class 'owns' this.

It is neither readable nor writeable outside the boundary of that class.

This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership.

psychoticRabbit wrote:

> Whatever happened to the 'discussion' component of these 'discussions'?

dunno. try to ask yourself, why repeating the same point again and again when you were given the answer and the rationale doesn't make a good discussion.

On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote:
> On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
>>
>> The same applies here. Encapsulation simply isn't broken by this feature.
>
> What you're saying, is in D, class encapsulation is really 'module' encapsulation.
>
> I get it. Fine. It's an intersting design decision.
>
> But, in doing that, D has shifted the boundary of class encapsulation, to a boundary that is outside the class.
>
> To me, that sounds like D has broken class encapsulation. I don't know how else one could describe it.
>
> I continue to think, that class encapsulation is sacred, a well defined, well understood, concept that has been around for a very long time.
>
> private could have still meant private, and surely someone could have come up with a different access modifier to mean 'private at module level'.
>
> Was that too hard the language designers?
>
> Was it not hard, but just to complex to implement?
>
> I don't get it.

I agree that class encapsulation is broken, well, not broken but just not a thing really. Don't think it's a bad thing though. Case in point, swift had private as file level access, swift 3 they introduced fileprivate [0] to do that instead and had private be scope level (which includes class level and is what you're referring to private being).

Swift 4 they reverted it .... kinda [1]

It was too inconvenient to not allow access to private members within a file in a language that allows extensions (think ufcs). So they compromised a bit here and went for decleration level which makes sense within their extension semantics. This would not work for D thought because ufcs is not really a type extension (i.e. not part of a type's typeinfo)

So now the difference is that private can be used in a file but only in a declaration and fileprivate can be used anywhere in a file. So they allow class encapsulation but at a file level. It's an interesting approach and quite neat.

Rust is also the same as D I believe. Module is the unit of encapsulation.

I wouldn't want private to change it's meaning quite frankly in the module system. I would not mind more control within a module though because, well, encapsulation. A Rust-ish approach were you can define a path [2] might allow for a lot more freedom but I'm not sure how well that would work with D.

Cheers

[0] https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
[1] https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
[2] https://doc.rust-lang.org/beta/reference/visibility-and-privacy.html

On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote:
> On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
>>
>> I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module".
>>
>
> what about a new access attribute (and no, I haven't though this through much):
>
> owned string _FirstName;
>
> (now the class 'owns' this.
>
> It is neither readable nor writeable outside the boundary of that class.
>
> This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership.

So, what's wrong with this?
===================================
module foo;
class Blah
{
    public int pub;
    private int priv;
}
===================================
module bar;

import foo;

void main()
{
   auto c = new Blah();

   c.priv = 42; // compile error
}
===================================

You can still code like Java, one file per class (module) and keep those private members protection across modules classes.

What's different with D is that the scope is the module not the class (package), and this is good. This is a trade-of, usually one codes related components in a module, thus frequently needs access to those components inside the module. You can have class, struct, functions, enums, static variables and templates in the same module, and pragmatically you will need to access private data on them. You still have the private to signal the intent, just that the philosophy is different when looking at the basic compilation unit.

On Tuesday, 13 March 2018 at 07:39:04 UTC, psychoticRabbit wrote:
>
> I don't have any objection to the idea that a module can have privileged access to members of classes within that model. It sounds sensible enough, if the module is a level of encapsulation also.
>
> My arguments is that, this was implemented in D, at the cost of removing the capacity for a class in the same module to protect it's own members (within the module). That's what I don't like about it.
>
> My other objection, as stated, is that D uses the same syntax as C++/C#/Java, but the semantics of that same syntax are completely different. I also don't like that.

If you are missing more fine grained encapsulation control: take a look at
https://wiki.dlang.org/Access_specifiers_and_visibility#package

If you are in debt, that encapsulation at module level is more superior with respect to encapsulation and expressiveness in comparison to class level, look at Fortran and Java 9.

And last but not least:

´´´
package myPackage;

public class Main {

    public static void main(String[] args)
    {
        System.out.println("Hello World!");
        myClass c = new myClass();
        c.myPrivateClassMember= "wtf";
        System.out.println(c.myPrivateClassMember);
    }

    private static class myClass
    {
        private String myPrivateClassMember; // private does not mean private anymore??
    }
}
´´´
(may the forum forgive me :p )

On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote:
> On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
>>
>> I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module".
>>
>
> what about a new access attribute (and no, I haven't though this through much):
>
> owned string _FirstName;
>
> (now the class 'owns' this.
>
> It is neither readable nor writeable outside the boundary of that class.
>
> This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership.

or another idea:

ownedBy T string _FirstName;

where T could be 'Module' (meaning it works the way it currently does. The module can read/write to it).

or T could 'Universe' (where universe means everyone can do whatever they want with it).

or T could be 'This'(so class can regain control overs its own members),

The default could be ownedBy Module, to retain existing behaviour.

I'd even go further, with extended attributes...

ownedBy Module Read string _FirstName;
ownedBy Module Write string _FirstName;
ownedBy Module ReadWrite string _FirstName;

On Tuesday, 13 March 2018 at 06:58:08 UTC, psychoticRabbit wrote:

>
> What you're saying, is in D, class encapsulation is really 'module' encapsulation.
>
> I get it. Fine. It's an intersting design decision.

"Enapsulation" in D means the same as it does in every other language -- hidden from the outside.

The purpose of encapsulation is to prevent client code from breaking when an internal API changes. That's exactly the level of encapsulation that D's private provides. Making private restrict access to the class would be like other languages, sure, but then it becomes over restrictive.

>
> But, in doing that, D has shifted the boundary of class encapsulation, to a boundary that is outside the class.

Nope. It's still hidden from the outside world. No one can read or write private class members *from the external API*.

>
> To me, that sounds like D has broken class encapsulation. I don't know how else one could describe it.
>
> I continue to think, that class encapsulation is sacred, a well defined, well understood, concept that has been around for a very long time.

Only if you view encapsulation as something other than "hidden from the outside world".


> private could have still meant private, and surely someone could have come up with a different access modifier to mean 'private at module level'.
>
> Was that too hard the language designers?
>
> Was it not hard, but just to complex to implement?
>
> I don't get it.

Any new keywords, or reuse of existing keywords, does make the language more complex. Everything that is added must have a reason. Private is module level because friend is so common in C++, i.e. people find it useful and it would be great to support something similar in D. Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision.