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.
