On Monday, 21 January 2013 at 14:06:49 UTC, eles wrote:
> 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.
>

I don't really understand the logic here. That seems very confused to me.

> 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.

That may happen. If it happen you'll have trouble; Actually enough trouble that I'm pretty sure that this private things will not be of any priority to your eyes.

And your point around refactoring is kind of moot, because if you refactor big a module into smaller one, you are, by definition refactoring that module. And the code affected by the private thing IS, by definition of private, in that module. No need to mess around with other code.

Some approach have been proposed to be able to refactor a module into a package, and that is probably a much more interesting way to go, as it solve a much broader range of issues.

On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic wrote:
> 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.
>

Package have nothing to do with the private discussion that take place here.

> 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.
>

Ideally, package should allow this in a way or another.

On Monday, 21 January 2013 at 14:29:32 UTC, deadalnix wrote:
> On Monday, 21 January 2013 at 14:06:49 UTC, eles wrote:
>> 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):
> I don't really understand the logic here. That seems very confused to me.

Just think about Andrey as being such C++ programmer that gave D a try and ran away. Why? Because it was puzzled to see that, despit being "private", the attribute is "public" (well, to some degree).

His first thought was that D should not be used into production environment.

OK? Andrey is one C++ programmer that you lose, you cannot convert him to D. Does D afford that?

On 1/21/13, deadalnix <deadalnix@gmail.com> wrote:
> Package have nothing to do with the private discussion that take place here.

It's completely relevant.

On Monday, 21 January 2013 at 14:34:50 UTC, eles wrote:
> Just think about Andrey as being such C++ programmer that gave D a try and ran away. Why? Because it was puzzled to see that, despit being "private", the attribute is "public" (well, to some degree).
>
> His first thought was that D should not be used into production environment.
>
> OK? Andrey is one C++ programmer that you lose, you cannot convert him to D. Does D afford that?

That is completely backward. D and C++ have very different needs in terms of visibility of symbols, especially if you think about the fact that namespace introduction in C++ come after visibility qualifiers. D have a module system that make the requirement very different.

Every time you change something people are used too, they get scared. Someone scared by a change they don't understand will not use D anyway. Given another behavior of private more C++ compliant, it is very likely that Andrey would have find something else to be scared of.

On Monday, 21 January 2013 at 14:46:52 UTC, deadalnix wrote:
> On Monday, 21 January 2013 at 14:34:50 UTC, eles wrote:
> Every time you change something people are used too, they get scared. Someone scared by a change they don't understand will not use D anyway. Given another behavior of private more C++ compliant, it is very likely that Andrey would have find something else to be scared of.

The point is some changes are useless, to not say they are bad. If D modified the "private", I think better decisions would have been to rename it too (ie. into "D_special_meaning_of_private")

Do not forget that D still needs to attract people from the C/C++ world. If you adress to them, at least be nice to them and do not scare them from the begining.

Also, C++ done *some* things right and those should be kept. At least, when correcting the bad things in C++, do not mess them more than it is necessary.

For me, for example, it is puzzling to see that the "private" meaning was modified, but kept the same name. I knew that Andrey's code is legal into D, still I find it unnatural and I understand his reaction. I had the same reaction.

In order to demonstrate privateness in a Hello World before of students, do I really need to go with TWO files?

C++ does not have UFCS. It does matter.

On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic wrote:
> 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.

Yes modules can be improved considerably and made much more practical. For example, you should be able to specify in the module what components are to be exported to a DI interface file and in what form. Currently  there's no control, and everything gets dumped in the DI, then you have to hand craft it to hide implementation details. If you want D to become more popular, you have to allow for the hiding of implementation details, and you have to make it simple for the programmer to do it.

We could do much better with a road map of what needs to be done with priorities set.

--rt

On 1/21/13 7:49 AM, eles wrote:
> Why make access protection dependent of how the source code is spread
> into files?

For the simple reason that files are the de facto unit of encapsulation for viewing and editing.

Andrei

On 1/21/13 9:41 AM, Andrej Mitrovic wrote:
> On 1/21/13, deadalnix<deadalnix@gmail.com>  wrote:
>> Package have nothing to do with the private discussion that take
>> place here.
>
> It's completely relevant.

FWIW I think they are distinct issues.

Andrei