Arbitrary abbreviations in phobos considered ridiculous

[Jonathan M Davis]

On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.180.1331149159.4860.digitalmars-d at 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