DIP16: Transparently substitute module with package

[deadalnix]

Le 30/03/2012 21:33, Andrei Alexandrescu a écrit :
> 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

You are reversing the logic. It have to be shown that it is not a 
problem to do the change. The other way around is flawed logic.