On Saturday, 12 May 2018 at 06:35:55 UTC, KingJoffrey wrote:

> Come on, your code example misses my point completely.
>
> Take this program below, for example, and tell me that class encapsulation is not broken in D:
>
> ===============================
> module test;
>
> import std.stdio : writeln;
>
> void main()
> {
>     Person p = new Person("King Joffrey");
>
>     writeln(p.getName); // I designed my class to return this.
>     writeln(p._name); // But D can bypass your intention completely.
>
>     p._name = "New King"; // even worse, D can nominate another king.
>     writeln(p._name);
> }

I think I'm missing something. Why is it a problem that you can do this? How do other languages prevent you from doing it?

On Tuesday, 15 May 2018 at 14:34:07 UTC, bachmeier wrote:
>
> I think I'm missing something. Why is it a problem that you can do this? How do other languages prevent you from doing it?

C# example (silly, but it demonstrates the point).

The problem is not so much D, but that C++/Java/C# programmers, and many from other languages (Go, Rust....) will expect private to mean private...not private..depending on....

They will expect the interface they defined, to be respected.

Then they'll start asking..wtf!@$#?   .. and end up in long threads like this one, trying to work out why the world is upside down (or seems like it).

And don't get me started on public being the default in D .. cause at some point..I gotta get some sleep.

--------------
public class Program
{
    public static void Main(string[] args)
    {
        Person p = new Person();
        //p.name = "King Joffrey"; // dude. this is private!
    }
}

public class Person
{
    private string name;
    public string getName() { return name; }
}

---------------

On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:
> The way you use the word "leak" make is sounds that this is unintentional, while in reality it is intentional by design. That why reading the specification is important!
>
> Alexander

Ya I guess you be right - but a leak is what it is to people who expect private to mean private. Which is not a small number of people ;)

And while I agree reading a spec is important. Language specs are not known for being trivial to go through and it's not really something you read but more of something you refer to, and that also probably for more advanced developers. This is not something you can expect newcomers or even intermediate level devs to go through. And the less you need to refer to a spec the better (i.e. more intuitive) a language is.

On Tuesday, 15 May 2018 at 10:19:58 UTC, KingJoffrey wrote:
> My own code in D had bugs, cause I didn't realise all my private parts were not just visible, but accessible by all the so called 'friends' around me. They could reach in a do whatever they want! Without my consent!

You've peaked my interest, could you give some details on one or more of these bugs?

On Tuesday, 15 May 2018 at 15:05:45 UTC, KingJoffrey wrote:

> The problem is not so much D, but that C++/Java/C# programmers, and many from other languages (Go, Rust....) will expect private to mean private...not private..depending on....
>
> They will expect the interface they defined, to be respected.

I'm not really in agreement with that. If you're coming from another language, you'll have to learn the differences. IMO D's solution is better...maybe you can convince the other languages to change.

I haven't read all of the (many) posts in this thread, so I'll leave it at that, since this has probably already been discussed. I didn't understand the example, but it's not actually the case that there's anything "broken", it's just different from what someone would expect if they tried to write C++ or Java in D.

On 5/15/2018 10:17 AM, aliak wrote:
> On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:
>> The way you use the word "leak" make is sounds that this is unintentional, while in reality it is intentional by design. That why reading the specification is important!
>>
>> Alexander
> 
> Ya I guess you be right - but a leak is what it is to people who expect private to mean private. Which is not a small number of people ;)
> 
> And while I agree reading a spec is important. Language specs are not known for being trivial to go through and it's not really something you read but more of something you refer to, and that also probably for more advanced developers. This is not something you can expect newcomers or even intermediate level devs to go through. And the less you need to refer to a spec the better (i.e. more intuitive) a language is.
> 
> 
> 

I concur with that.  When I first started learning D (coming from a C# background), I figured that I already knew all of the OOP stuff and didn't dig too deeply into it, figuring that it worked pretty close to the same as C#.  It did catch me off guard when I first realized how it really worked in D.  But the work around (putting it in its own module), seemed pretty trivial and is what I typically do in C# anyways, so it didn't bother me too much.

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
> On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:
>> On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:
>>> On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:
>>>> [...]
>>>
>>> If 'getting a module to respect the enscapsulation boundaries the programmer puts in place would change the language so 'fundamentally', then the language 'already' presents big problems for large complex application development.
>>>
>> Evidence for this claim please.
>
> - Object independence
> - Do not violate encapsulation
> - Respect the interface
>
> All large software projects are done in (or moving toward) languages that respect these idioms.
>
> Those that don't, are the ones we typically have problems with.
>
> Isn't that evidence enough?

That's not evidence, that's pure opinion. There's not a shred of data in that list.

On Tuesday, May 15, 2018 12:21:23 Dlang User via Digitalmars-d wrote:
> On 5/15/2018 10:17 AM, aliak wrote:
> > On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:
> >> The way you use the word "leak" make is sounds that this is unintentional, while in reality it is intentional by design. That why reading the specification is important!
> >>
> >> Alexander
> >
> > Ya I guess you be right - but a leak is what it is to people who expect private to mean private. Which is not a small number of people ;)
> >
> > And while I agree reading a spec is important. Language specs are not known for being trivial to go through and it's not really something you read but more of something you refer to, and that also probably for more advanced developers. This is not something you can expect newcomers or even intermediate level devs to go through. And the less you need to refer to a spec the better (i.e. more intuitive) a language is.
>
> I concur with that.  When I first started learning D (coming from a C# background), I figured that I already knew all of the OOP stuff and didn't dig too deeply into it, figuring that it worked pretty close to the same as C#.  It did catch me off guard when I first realized how it really worked in D.  But the work around (putting it in its own module), seemed pretty trivial and is what I typically do in C# anyways, so it didn't bother me too much.

I think that if there's an actual problem here, it's the fact that how private works in D is surprising to folks coming from languages like C++, C#, or Java. IMHO, D's approach works extremely well, but if you don't understand what it is, you risk problems, just like with any other feature that you don't understand properly. And to better deal with that, we probably need more in the way of documentation geared towards teaching newbies. The "spec" is pretty poor in that it's not precise enough to be a spec, meaning that it doesn't really do its job in that respect, but it's also not really written with the idea that it's teaching someone, so it doesn't do a great job teaching the language either. There's a lot of great information there, but it's ultimately not all that accessible for many folks.

Though if someone expects to be able to just jump into any language and use it without reading up on how it works, they're just shooting themselves in the foot. And surprisingly often, that seems to be how many folks operate.

Ultimately, if newcomers don't want to be tripped up on stuff like this, their best bet is probably to read books like Andrei's "The D Programming Language" and Ali's "Programming in D."

https://wiki.dlang.org/Books

- Jonathan M Davis

On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:
> Though if someone expects to be able to just jump into any language and use it without reading up on how it works, they're just shooting themselves in the foot. And surprisingly often, that seems to be how many folks operate.

It works pretty well because programming languages tend to be very similar. Knowing Java, you can pretty much just write C#. Knowing C++ and a bit of lore, you can transition to Java pretty easily. But it's a lot harder to transition from C# to F#, for instance, or to OCaml, or METAFONT.

You might be surprised that some things are missing. You might not know about some things that would help you. You might be writing code inefficiently, and you will likely write code that's not idiomatic, that's hard for others to read. But you can still get things done.

And then you encounter things that break, and you look for other ways of doing that.

D's protection attributes are not that different from Java's, so things look the same at first. And when they're different, they differ in a hard-to-spot way.

There isn't much cure for this.

On Tuesday, 15 May 2018 at 15:19:33 UTC, Jesse Phillips wrote:
> On Tuesday, 15 May 2018 at 10:19:58 UTC, KingJoffrey wrote:
>> My own code in D had bugs, cause I didn't realise all my private parts were not just visible, but accessible by all the so called 'friends' around me. They could reach in a do whatever they want! Without my consent!
>
> You've peaked my interest, could you give some details on one or more of these bugs?

It's simple.

Write a non-member function, contained in the same module as a class, and accidently use a private class member instead of the public getter/setter defined by the interface of that class.

It's human error, that will occur time and time again, but will *never* get picked up in D, except through a debugging session, because D does not consider this an error.

How can it, if private is not really private?

Now the burden is back on the programmer again.

Be careful what you put into a module.