DIP16: Transparently substitute module with package

[Andrei Alexandrescu]

On 3/30/12 1:39 PM, Jonathan M Davis wrote:
> However, I'm very nervous about the second part. e.g. std.sort instead of
> std.algorithm.sort seems like a bad idea to me. It increases the odds of name
> conflicts for little benefit.

Example?

> Not to mention, it'll make it a lot more confusing
> to find what modules stuff is actually in if people start doing stuff like
>
> std.sort(arr);
>
> In the case of sort, you may know where it's from - particularly since it's so
> common - but the less well-known the function is, the less likely that is at
> all obvious where it comes from, and if you're dealing with 3rd party
> software, then it wouldn't be at all obvious. For instance, how would you know
> that party.foo is really party.bar.foo? You wouldn't.

Why should you?

> Being so lax about
> importing could really harm code readibility (and maintainibility, since it
> increases the odds of name clashes). So, I'm inclined to say that that is a
> _bad_ idea.

Maybe if you produce a solid example, I'd be convinced.


Andrei