Focus

deadalnix deadalnix at gmail.com
Mon Jan 21 06:29:31 PST 2013


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.


More information about the Digitalmars-d mailing list