On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright wrote:
> On 1/18/2013 4:55 PM, Andrey wrote:
> This all falls apart once you decide you need "friend" access.

What is wrong with this POV is that the original class no longer has a word to say if she wants to be friended by someone.

In C++ the class has a word to say: if it does not declare: "hey! you will be my friend!", then nobody can come there to say: "hey! I consider myself your friend (even if you don't want it), so I will mess up your internal state!"

On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
> On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
> […]
> This D development community should put effort into making GDC and LDC
> the primary D tools, ensuring that the latest D version is always

I second that.

On Monday, 21 January 2013 at 10:42:17 UTC, deadalnix wrote:
> On Monday, 21 January 2013 at 08:34:49 UTC, Paulo Pinto wrote:
>> Go might eventually succeed in replacing C, Google just needs to make Go a first class language for Android development.
>>
>
> Go has no chance to replace C as too many low level features are missing. But yes, it can become pretty big !

That is debatable, as most things are possible via unsafe + syscall.

Already proven in another GC enabled system languages.

That the industry needs to have them shoved by their throat like in Java's case, that is another matter.

--
Paulo

On Monday, 21 January 2013 at 12:31:16 UTC, Russel Winder wrote:
> On Mon, 2013-01-21 at 09:34 +0100, Paulo Pinto wrote:
> […]
>> Yes. I remember looking at Groovy around 2000 timeframe and not giving
>> too much consideration.
> […]
>
> Just to ensure the history as determined by Google search is at least
> fairly reasonable, Groovy started in mid to late 2003 had a hiccup mid
> 2004, and really got moving in late 2004.

Yeah, it might have been 2003.

I have written "around 2000", because I wasn't sure when exactly.

This was the time when Groovy was supposed to be made part of Java.

Ok, it was JSR-241, http://www.jcp.org/en/jsr/detail?id=241

I got the date wrong by 4 years it seems.

--
Paulo

On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
> On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright wrote:
>> On 1/18/2013 4:55 PM, Andrey wrote:
>> This all falls apart once you decide you need "friend" access.
>
> What is wrong with this POV is that the original class no longer has a word to say if she wants to be friended by someone.
>
> In C++ the class has a word to say: if it does not declare: "hey! you will be my friend!", then nobody can come there to say: "hey! I consider myself your friend (even if you don't want it), so I will mess up your internal state!"

Only if that class is in the same module.

This is being blown completely out of proportion.

A few things to consider:

- Lots of languages don't have access control at all, yet somehow people use them without problem.
- As far as I can see, the DMD source has very few private variables, yet very few (if any) bugs are caused by people messing up other people's variables.
- If you have one class per module, D is no different to C++/Java/C#.

On Monday, 21 January 2013 at 13:16:03 UTC, Peter Alexander wrote:
> On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
>> On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright wrote:
>>> On 1/18/2013 4:55 PM, Andrey wrote:
> - Lots of languages don't have access control at all, yet somehow people use them without problem.

Lots of languages do not even have classes. Lots of languages do not even have functions. Lots of languages are... assembler.

> - As far as I can see, the DMD source has very few private variables, yet very few (if any) bugs are caused by people messing up other people's variables.

In the beginning, C++ programs had very few bugs. Then, real coding in C++ happened. BTW, DMD (not phobos) source is C++ (https://github.com/D-Programming-Language/dmd/blob/master/src/arrayop.c), not D.

> - If you have one class per module, D is no different to C++/Java/C#.

Yes... And if you define:
struct var *p2=new_from_data(p1->a, p1->b, p1->c);
then you have a copy constructor... Straight, isn't?

On Monday, 21 January 2013 at 13:32:35 UTC, eles wrote:
> On Monday, 21 January 2013 at 13:16:03 UTC, Peter Alexander wrote:
>> On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
>>> On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright wrote:
>>>> On 1/18/2013 4:55 PM, Andrey wrote:
> In the beginning, C++ programs had very few bugs. Then, real coding in C++ happened. BTW, DMD (not phobos) source is C++ (https://github.com/D-Programming-Language/dmd/blob/master/src/arrayop.c), not D.


BTW, Walter, pls take a moment and change the extension of those files from .c to .cpp.

On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
> On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:
>> On 1/18/2013 2:16 PM, Andrey wrote:
>>
>> This is by design, not a bug. All code in a module has access to all private members in that same module. This obviates the need for the C++ "friend" declarations.
>
> Yes, but that is a bad choice. The simplest argument against it it is that it is a departure of C++. Yes, you've made "private" like Java (package), but that's not the first intended audience.
>
> If you cannot go back with private acting like C++ private, then at least introduce an "internal" specifier for things that truly belongs to the class only (ie: the C++ private).
>
> You could have:
>
> internal
> private
> package
> protected
> public
> export
>
> or
>
> private
> semiprivate // well? better ideas?
> package
> protected
> public
> export
>
> Why make access protection dependent of how the source code is spread into files?

What would be the point ? You'll have the implementation and the function definition under the nose anyway as it is in the same file.

If something should be private from your code, what is your code doing is the same module ?

On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:
> On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
>> On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:
>>> On 1/18/2013 2:16 PM, Andrey wrote:
>>>
> What would be the point ? You'll have the implementation and the function definition under the nose anyway as it is in the same file.
>
> If something should be private from your code, what is your code doing is the same module ?

1. Quoting Andrey's original post (3rd on this thread):

"So, when you observe this situation, it becomes really hard to
pursue fully fledged commercial development with D."

So, if you think that D is so string that it allows itself such ingenuities that makes C++ programmers giving it a try to scream away from D, then fine. D already has difficulties in being accepted by corporations (and I thing that lack of gcc integration is the strongest difficulty). But, now, imagine that you present D in front of a bunch of hardened C++ programmers and you have to explain those already skeptikal people that thes should not scream when they see Andrey's originally posted code. It is not also about D's own way, D still has to make some compromises to be accepted. In 10 years, it will be, maybe, the reference. IT IS NOT TODAY.

2. That file/module could be really huge. Several succesive programmers working on the same file/module could be of various expertise levels and not aware of such subtleties. Refactoring means also moving a lot of code around and you will find yourself needed to go back to that file where the code was originally defined and modify the "private" into "package" if you still want your code to compile. As a rule, during refactoring, it is a bad thing to touch (or be needed to touch) other code than the one you are messing up with, be in the same source file or no.

On 1/21/13, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> This is being blown completely out of proportion.

I don't think so.

Consider that currently it's impossible to hide any symbols from a user if they are located in subpackages. Which means you're forced to either put everything into the same package and use the package access specifier, or put everything into the same module.

The problem I have with this is it makes it impossible to separate implementation-specific modules into their subpackages without giving access of these symbols to the user. Consider that the following would make a nice folder structure for a library:

lib/gui.d
lib/platform/win32/gui.d
lib/platform/posix/gui.d

Unfortunately everything in lib/platform must be public in order for gui.d to use it, and as a consequence user-code ends up having access to these platforms-specific implementation modules.

You could move everything into the lib folder and use the package access specifier. That also means class methods must have package access to prevent the user from invoking them, but this automatically makes them non-virtual.

Bottom line is, the module system and access specifiers can use some improvements. Language XYZ might do something in its own way, but D is a language of its own and we should feel free to innovate.