On 03/07/2012 10:47 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:
"Jonathan M Davis"<jmdavisp...@gmx.com> wrote in message
news:mailman.180.1331149159.4860.digitalmar...@puremagic.com...
On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
In fact there is no such thing as a top level in D. (I was quite
surprised to learn that a few years ago, and found it quite
brilliant of Walter.)
True, but if names conflict, you then have to worry about using the
full import paths for symbols, which can get annoying.
[...]
I thought that's what module aliases were for.
They can help, but thanks to the fact that they impact any other modules
that
import that module, they're often unacceptable.
That's just an implementation bug, though, isn't it? And wasn't it recently
fixed?
It's a design issue. Yes, the bug that private didn't affect aliases was fixed,
but private does _not_ hide symbols. It only makes them inaccessible. So, for
instance, if std.datetime were to alias std.string.indexOf to indexOf, then
every module which imports both std.algorithm and std.datetime would then have
to either alias std.algorithm.indexOf themselves or use the full import path.
So, as it stands, private aliases are pretty much useless. It's just like how
private functions can affect function overloading in spite of the fact that
other modules can't use them.
This completely follows how private is designed. So, it's not a bug. But there
are definitely arguments for changing how private works (e.g. the fact that you
can't really alias stuff within a module without affecting other modules). The
trick is convincing Walter to change it.
- Jonathan M Davis
There is absolutely no remotely valid argument against changing the
behavior that does not involve a discussion of the compiler internals.
