View mode: basic / threaded / horizontal-split · Log in · Help
January 21, 2013
Re: Focus
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.
January 21, 2013
Re: Focus
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.
January 21, 2013
Re: Focus
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?
January 21, 2013
Re: Focus
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.
January 21, 2013
Re: Focus
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.
January 21, 2013
Re: Focus
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?
January 21, 2013
Re: Focus
C++ does not have UFCS. It does matter.
January 21, 2013
Re: Focus
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
January 22, 2013
Re: Focus
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
January 22, 2013
Re: Focus
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
2 3 4 5 6 7
Top | Discussion index | About this forum | D home