Walter Bright wrote:
> kris wrote:
> 
>> The same thing happened with Associative Arrays: you didn't bother to solicit opinion on either of the two occasions when it was changed; and then subsequently complained when people still found issue with you alternate changes. It's still not right to this day. I see the same pattern here. And for what?
> 
> 
> I did implement it according to the suggestions - and then the people who made those suggestions had issue with it. So I take issue(!) with your statement that I did it in a vacuum. I preferred the original design, and the change caused me a lot of work updating things like dmdscript which extensively used AA's.

Well, the last time you changes things, you may recall there were a flurry of posts saying "huh? what the heck happened here?". You subsequently made a post noting how nobody liked AA even after you changed it twice. I was present on both occasions, and it sure seemed like you made the changes in a vacuum. On both ocassions.

> 
> 
>> Anyone would think we were trying to sabotage the language,
> 
> 
> Nobody thinks that. We are all trying to get the best design for D possible. That doesn't mean we are all going to agree on what the best design is. There's no cause to label a difference of opinion as sabotage, or any of the other epithets bandied about in this disagreement (or some of the previous ones).

It's far beyond a difference of opinion, Walter. Just look at the swell of experienced developers here literally begging for you to make a small change. Instead of listening carefully with an open mind, you project a closed and vacant shell. I think you'd have to agree that this is one serious issue.

Why do you simply stonewall it? The projection is as though you're not even open to discussion.

On Tue, 11 Jul 2006 04:16:29 -0700, kris <foo@bar.com> wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> The same thing happened with Associative Arrays: you didn't bother to solicit opinion on either of the two occasions when it was changed; and then subsequently complained when people still found issue with you alternate changes. It's still not right to this day. I see the same pattern here. And for what?
>>   I did implement it according to the suggestions - and then the people who made those suggestions had issue with it. So I take issue(!) with your statement that I did it in a vacuum. I preferred the original design, and the change caused me a lot of work updating things like dmdscript which extensively used AA's.
>
> Well, the last time you changes things, you may recall there were a flurry of posts saying "huh? what the heck happened here?". You subsequently made a post noting how nobody liked AA even after you changed it twice. I was present on both occasions, and it sure seemed like you made the changes in a vacuum. On both ocassions.
>
>>
>>> Anyone would think we were trying to sabotage the language,
>>   Nobody thinks that. We are all trying to get the best design for D possible. That doesn't mean we are all going to agree on what the best design is. There's no cause to label a difference of opinion as sabotage, or any of the other epithets bandied about in this disagreement (or some of the previous ones).
>
> It's far beyond a difference of opinion, Walter. Just look at the swell of experienced developers here literally begging for you to make a small change. Instead of listening carefully with an open mind, you project a closed and vacant shell. I think you'd have to agree that this is one serious issue.
>
> Why do you simply stonewall it? The projection is as though you're not even open to discussion.

I think you're being unfair, I'm not getting that impression.

Regan

John Reimer wrote:
> In article <e8unve$2qjl$1@digitaldaemon.com>, Lucas Goss says...
>>
>> I just wish I knew who broke the dam because I don't like this water under the bridge. Having the FQN as default seems to be the best solution as any keyword before import seems like a kludge. 
> 
> No, it's no kludge.  We do it with "private" and "public" already :P, so having
> a keyword in front of import is a non-issue.  If one really doesn't like it
> there, they can change the format like much of anything in a structured
> language.  That's a style issue, not a language one.
> 

Point taken.

> ...
> # with (module1)
> #      import func1, Struct1, Class1;
> 
> Elegance is not impossible to attain. We just have to be willing to look for it.
> Consistancy is perfectly attainable too.  We just have to be willing to avoid
> tunnel vision.
> 

I understand what you're saying, but I also get what Walter is saying. This is already mostly attainable with alias, except that additionally you want selective imports. However I fail to see what (great) value selective imports have.

> 
>> (1)
>> import std.math.*;
>> import std.stdio.writefln;
>> import std.stdio.writef;
>>
>> ...
> 
> Why use '*'?  That unnecessary since the current import already does that.
> 

In the line before that I was saying it would be nice if water wasn't already under the bridge, because then we could do FQN by default. If FQN was the default, then there would need to be a way to import everything. Sorry for not making that clear.

>> (2)
>> static import math;
>> import std.stdio : writefln, writef;
>>
> 
> So you don't mind the "static" in front of import?
> 

I was saying I like the first way and how it lays out as opposed to the second way. Sorry for not being clear enough. I don't like the static and I'm not even sure it's necessary.

>> The argument that a rename of the base library (in this case std.stdio) would be a pain to update I don't think holds. A rename is a simple find and replace, which most text editors do simply. The vertical layout of the first for me is easier (in my opinion) to read, and anything before import makes the statement more confusing (as in the static).
> 
> I'm having difficulty following what you are trying to say.
> 
> The argument holds very well still because we could make our editors do a whole
> lot of things, but that doesn't make it right.  We're talking about making a
> language clear and easy to understand.
> 

I was talking about the argument of renaming the library would cause a difficulty in updating the aliases. As far as making a language clear and easy to understand, I don't see much difference in clarity with:

import lib.longname.x;
alias lib.longname.x.func1 func;
alias lib.longname.x.Class1 class;

import lib.longname.y;
alias lib.longname.y.func1 func_extra;
alias lib.longname.y.Class1 Class_extra;

and

with (lib.longname.x)
	import func1 as func, Class1 as class;

with (lib.longname.y)
	import func1 as func_extra, Class1 as Class_extra;


They both seem to be pretty clear.

Lucas

Regan Heath wrote:
> I think you're being unfair, I'm not getting that impression.

You are most welcome to form your own impression, Regan. I'm simply noting mine. Is this the longest thread ever? Pretty much everyone here is asking for something better. Go figure *shrug*

Walter Bright wrote:
> xs0 wrote:
>>> The imports can be placed anywhere in the module, even (ugh) inside class definitions. 'import' isn't any easier to search for than 'alias'.
>> I was wondering - is there any good reason to allow imports everywhere?
> 
> It's usually a good idea to make things as orthogonal, with as few special case, as possible. Since imports are a declaration, they should work wherever declarations work.

OK, I guess, I never thought of them as declarations... Must be too much Java ;)

>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
> 
> It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.

Well, I agree that consistency is often better than special case rules, but I don't agree this is one of those cases. Just so I wouldn't be biased by my own experience, I went and counted all the imports in mango.io, which confirmed my suspicions - the vast majority of imports are private.. My count is 173 imports, 32 of which were public (~18%). If it wasn't for one-class-per-module Mango seems to be doing, my guess is that there'd be no public imports at all, as most of them seem to just be convenience imports for various interfaces.

And I agree with Lars - it's not too late and public being the default for everything may not be the best option anyway. For example, in Java the default is package-private, which would roughly translate to module-private in D. I rarely need to change that default (i.e. specify a different protection), as things are usually pretty consistent with what I want that way.

Finally, your own stated major goal for D is to "improve productivity .. by adjusting language features so that common bugs are eliminated from the start", and from what I've seen in the newsgroups, forgetting to import privately is definitely a common bug, and nobody seems to expect an unqualified import to be public.


xs0

On Tue, 11 Jul 2006 20:47:34 +1000, Walter Bright <newshound@digitalmars.com> wrote:

> xs0 wrote:
>>> The imports can be placed anywhere in the module, even (ugh) inside class definitions. 'import' isn't any easier to search for than 'alias'.
>> I was wondering - is there any good reason to allow imports everywhere?
> It's usually a good idea to make things as orthogonal, with as few special case, as possible. Since imports are a declaration, they should work wherever declarations work.


Does this mean you no longer mind imports inside a class definition, implying that the scope of the import is limited to the class members.


>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
>
> It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.

Rubbish! All my import statements in modules that are meant to be imported themselves already have the 'private' attribute. This is just extra stuff that D is forcing me to use if I want clean APIs. The 'public' by default for imports (and anything else) is just causing me to do extra work to write safe code. I think it was a dumb decision and should be reversed before v1.0 is advertised. I have no code that would need changing 'cos I already use defensive coding. 'private' be default would make defensive coding just so much easier to do.

D has got so many things right that ugly warts like this stick out promenantly.

-- 
Derek Parnell
Melbourne, Australia

On Tue, 11 Jul 2006 04:45:44 -0700, kris <foo@bar.com> wrote:
> Regan Heath wrote:
>> I think you're being unfair, I'm not getting that impression.
>
> You are most welcome to form your own impression, Regan. I'm simply noting mine. Is this the longest thread ever? Pretty much everyone here is asking for something better. Go figure *shrug*

This thread is full of miss-understanding and confusion about; what the problems are, what the suggestions are, what the current behaviour is, what the suggested behaviour will be .. etc that I'm not sure anything constructive is going to come from it.

At the very least I hope everyone has learnt something about how the current import system works, or how alias can be used (I didn't realise you could alias a module name, or part of a module name, cool!), from that new understanding perhaps something can be built?

I don't think questioning Walters motives is particularly helpful, at best he ignores it, at worst it makes him less inclined to listen to you .. but, as you say, you're welcome to share your impression .. I just wonder how much 'good' it does.

Regan

On Tue, 11 Jul 2006 14:01:12 +0200, xs0 <xs0@xs0.com> wrote:
> Walter Bright wrote:
>> xs0 wrote:
>>>> The imports can be placed anywhere in the module, even (ugh) inside class definitions. 'import' isn't any easier to search for than 'alias'.
>>> I was wondering - is there any good reason to allow imports everywhere?
>>  It's usually a good idea to make things as orthogonal, with as few special case, as possible. Since imports are a declaration, they should work wherever declarations work.
>
> OK, I guess, I never thought of them as declarations... Must be too much Java ;)
>
>>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
>>  It's too late for that, sorry. Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier.
>
> Well, I agree that consistency is often better than special case rules, but I don't agree this is one of those cases. Just so I wouldn't be biased by my own experience, I went and counted all the imports in mango.io, which confirmed my suspicions - the vast majority of imports are private.. My count is 173 imports, 32 of which were public (~18%). If it wasn't for one-class-per-module Mango seems to be doing, my guess is that there'd be no public imports at all, as most of them seem to just be convenience imports for various interfaces.
>
> And I agree with Lars - it's not too late and public being the default for everything may not be the best option anyway. For example, in Java the default is package-private, which would roughly translate to module-private in D. I rarely need to change that default (i.e. specify a different protection), as things are usually pretty consistent with what I want that way.
>
> Finally, your own stated major goal for D is to "improve productivity .. by adjusting language features so that common bugs are eliminated from the start", and from what I've seen in the newsgroups, forgetting to import privately is definitely a common bug, and nobody seems to expect an unqualified import to be public.

I'd prefer if imports were private by default. Making everything public may make it easier to remember initially but once you know something it really doesn't matter if it's the same as something else. So, while it may help the beginner learn and remember it, it penalizes the every day user by making it harder and more verbose to code in a 'clean' fashion.

Regan

John Reimer wrote:
> Actually, I just want to make a correction.  The problem you describe, Don, is very much related to this whole issue (after I did some reading up on the name collision thing to understand it more), but I still don't consider the "static import" a proper fix.
> 
> -JJR
> 

The FQN import is a proper fix for *that* problem. (which was an issue that kris originally brought up in the beginnings of this thread)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Walter Bright wrote:
> kris wrote:
>> Walter Bright wrote:
>>> Ivan Senji wrote:
>>>
>>>> Sure I could use
>>>>
>>>> static import m2;
>>>> alias m2.func f2;
>>>>
>>>> And that would be an improvement but it is still longer (and arguably
>>>> less understandable) than:
>>>>
>>>> import m2.func as f2; ;) :)
>>>
>>>
>>> Let's say you're going to do more than one:
>>>
>>> static import m2;
>>> alias m2.func f2;
>>> alias m2.abcd f3;
>>> alias m2.efgh f4;
>>>
>>> vs:
>>>
>>> import m2.func as f2;
>>> import m2.abcd as f3;
>>> import m2.efgh as f4;
>>>
>>> Not much of a difference. I'm also not understanding why alias is hard to understand.
>>
>>
>> You've seen the requested syntax for this option, Walter. Let's revisit it again:
>>
>> # with m2 import func, abcd, efgh;
> 
> The equivalent would be:
> 
>     with m2 import func as f2, abcd as f3, efgh as f4;

Just curious, why not:

import from m2 func as f2, abcd as f3, efgh as f4;
or
import with m2 func as f2, abcd as f3, efgh as f4;

because then it is more consistent both for D (all imports start with 'import') and in pure english language terms (starts with a verb instead of a preposition like other C-lineage languages do with their /include/import/using).