Derek Parnell wrote:
> *Please* do not overload the "static" keyword with yet another definition.  I have no idea what "static inport" means as a natural phrase. It does not  imply or suggest anything to me. Is it an import that is down at compile  time (of course it is 'cos that's when import statements are used), or is  it something that doesn't change size during the run-time, or is it  something that retains its place in RAM during the life of the execution?  Oh no, that's right - in this context it means that you have to FQN  references. Doh! Bloody obvious isn't it?

I'm afraid I agree.

When I first saw "static import", the above quote was literally what I went through.

The word "static" is not exactly transparent here. (Not that I could come up with a good alternative off hand.)

xs0 wrote:
> Tom S wrote:
> 
>> Another downside is that, the selective import using the 'with' construct only imports these symbols into the current scope, while 'static import' allows you to access all symbols from the imported module if you use a fully qualified name. This is as evil as the "'private', yet not private" symbols in modules.
> 
> While I support improving import (particularly allowing import of single symbols), I think you're exaggerating here. There is actually nothing wrong if all FQNs from a module are accessible (if private worked, anyway ;), as most all of the problems arise only with unqualified names.. In fact, some languages (e.g. Java) allow access via FQN without even specifically importing anything, and I never heard referred to that feature as evil before :)
> 
> That private symbols are visible is pure evil, though :) They should behave as if they don't exist to outside their module, that being the whole point of tagging something as private.
> 
> 
> xs0

I must strongly reinforce this statement. There is nothing wrong with FQNs being automatically available in a program (it's how Java and C# work), in fact, I strongly prefer this behavior and am planning to implement it in D when we get the FQN import. (news://news.digitalmars.com:119/e8r8tt$10cf$3@digitaldaemon.com)

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

John Reimer wrote:
> In article <optcf1efmv23k2f5@nrage>, Regan Heath says...
> 
>>On Sun, 9 Jul 2006 19:15:29 +0000 (UTC), John Reimer  <John_member@pathlink.com> wrote:
>>
>>>In article <e8rhud$1cca$1@digitaldaemon.com>, Deewiant says...
>>>
>>>>John Reimer wrote:
>>>>
>>>>>Also, for selective import, I think using "from" instead of "with"  looks much
>>>>>better.
>>>>>
>>>>
>>>>"from" is a quite common variable name though, so introducing it as a  keyword
>>>>would probably break a lot of code.
>>>>
>>>
>>>
>>>It is?  I don't see "from" very often.  Seems like an unusual name for a
>>>variable.  Saying it will break "a lot" of code seems like an  exaggeration.
>>
>>You don't write a mail server ;)
>>
>>Regan
> 
> 
> 
> LOL!  Yes, you are right!  Touche! :D

Then again, the compiler knows that in this context "from" simply can't be a variable name.

Bruno Medeiros wrote:
> xs0 wrote:
>> Tom S wrote:
>>
>>> Another downside is that, the selective import using the 'with' construct only imports these symbols into the current scope, while 'static import' allows you to access all symbols from the imported module if you use a fully qualified name. This is as evil as the "'private', yet not private" symbols in modules.
>>
>> While I support improving import (particularly allowing import of single symbols), I think you're exaggerating here. There is actually nothing wrong if all FQNs from a module are accessible (if private worked, anyway ;), as most all of the problems arise only with unqualified names.. In fact, some languages (e.g. Java) allow access via FQN without even specifically importing anything, and I never heard referred to that feature as evil before :)
>>
>> That private symbols are visible is pure evil, though :) They should behave as if they don't exist to outside their module, that being the whole point of tagging something as private.
>>
>>
>> xs0
> 
> I must strongly reinforce this statement. There is nothing wrong with FQNs being automatically available in a program (it's how Java and C# work), in fact, I strongly prefer this behavior and am planning to implement it in D when we get the FQN import. (news://news.digitalmars.com:119/e8r8tt$10cf$3@digitaldaemon.com)
> 

The one problem with that may be compilation speed. I suspect that a big part of  Java's compile-time and load-time problems are because of all the symbol loading it has to do for a typical class path to enable things like automatic FQN availability. At the command line, the C# compiler actually isn't that fast either for small programs, but in the IDE it seems fast because all this stuff is pre-loaded.

Once you implement it, I'd be interested in how it effects compilation speed. Maybe DWT would be a good test bed for that too - there is already an all.d for that that could be easily copied and changed.

If it doesn't effect things too much, then I think the Phobos distro. could use an "allfqn.d" too just for the simple expedient it would offer for teaching, and maybe things like replacing common Perl and Python scripts with D. Maybe "all.d" is too much, and could just be replaced with "commonfqn.d" + things like "mathfqn.d", etc?

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.
> 
>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
> 
> 
> It's too late for that, sorry. 

AAARRGGGHHHHH!!!!!

I've taken it for granted this was implicitly agreed to be fixed for months ago.

> 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.

Importing is conceptually distinct enough, so nobody would even notice this "inconsistency".

Please reconsider.

(As noted earlier, broken code, in this case, is easily fixed with a global replace of "import" to "public import".)

>> I must strongly reinforce this statement. There is nothing wrong with FQNs being automatically available in a program (it's how Java and C# work), in fact, I strongly prefer this behavior and am planning to implement it in D when we get the FQN import. (news://news.digitalmars.com:119/e8r8tt$10cf$3@digitaldaemon.com)
> 
> The one problem with that may be compilation speed. I suspect that a big part of  Java's compile-time and load-time problems are because of all the symbol loading it has to do for a typical class path to enable things like automatic FQN availability. At the command line, the C# compiler actually isn't that fast either for small programs, but in the IDE it seems fast because all this stuff is pre-loaded.

I don't think it would affect compilation speed at all. Stuff only needs to be looked up when referenced, and if referenced, it needs to be imported anyway.

As for slowness of Java compilation, I'd say the biggest speed killer is the fact that the compiler is written in Java itself - Java is the least compiler-friendly language I know.. D is, of course, the best (imho).


xs0

Sean Kelly 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.
> 
> 
> Not to get off topic, but that was a pretty hot issue and a lot of ideas were thrown around (as with this now).  I preferred the old syntax as well but wasn't willing to press the issue and things heated up.  And by the end of the discussion I don't think there was any clear consensus on what the changes should be.  I suspect this is why everyone was a bit surprised at the changes--any changes would have been at least a bit surprising.  I think what was lacking there was public evidence of any sort of decision.  At some point things just sort of died down and the next release contained a new implementation built from the conclusions you had drawn (accurate or no).  It would have helped immensely if, before making any changes, there had been a post outlining your conclusions and the changes you intended to make. 

That last sentence deserves to be read again!

> This would inevitably have sparked more discussion, but if it's a change you don't find particularly appealing anyway, I think it's worth making sure the dissenters have no right to complain after the fact :-)

Good point.

>>> 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).
> 
> 
> I think part of the problem is that large public forums doesn't lend themselves well to directed discussion, and the general trend in d.D, simply because of the large number of participants, is that any such discussion be comes frustratingly garbled.  You don't reply to every person who feels they said something deserving a response, and people begin to feel they're being deliberately ignored.  As Kris started this discussion in the first place, I suspect it's particularly frustrating to him that it suffer the fate of all such discussions here, and that his posts are some of those not offered considered responses.  Not to mention that this is an issue he appears to have spent a tremendous amount of time thinking about, and obviously feels quite strongly about as well.

Sometimes I feel Walter has been a bit terse, especially when something is /clear/ to him. Static import is a case in point. This whole thread may have been a lot shorter if the merits of Static import would have become adequately explained from the outset to more people.

> Assuming you're considering any change as a result of this conversation, perhaps the details could be settled explicitly, either here or in a separate thread?  I think everyone has said their piece at this point, and it would probably help everyone cool down a bit if things wrapped up with a suggested plan, even if the plan is to not change a thing for reasons X Y and Z.

Good suggestion!

xs0 wrote:
> 
>>> I must strongly reinforce this statement. There is nothing wrong with FQNs being automatically available in a program (it's how Java and C# work), in fact, I strongly prefer this behavior and am planning to implement it in D when we get the FQN import. (news://news.digitalmars.com:119/e8r8tt$10cf$3@digitaldaemon.com)
>>
>> The one problem with that may be compilation speed. I suspect that a big part of  Java's compile-time and load-time problems are because of all the symbol loading it has to do for a typical class path to enable things like automatic FQN availability. At the command line, the C# compiler actually isn't that fast either for small programs, but in the IDE it seems fast because all this stuff is pre-loaded.
> 
> I don't think it would affect compilation speed at all. Stuff only needs to be looked up when referenced, and if referenced, it needs to be imported anyway.
> 

I don't think that is correct for the reference compiler, because Walter's 'static import' proposal still imported the entire module (probably because the way the compiler works now is to 'load' an entire imported module, IIRC).

> As for slowness of Java compilation, I'd say the biggest speed killer is the fact that the compiler is written in Java itself - Java is the least compiler-friendly language I know.. D is, of course, the best (imho).
> 
> 
> xs0

Dave wrote:
> xs0 wrote:
>>
>>>> I must strongly reinforce this statement. There is nothing wrong with FQNs being automatically available in a program (it's how Java and C# work), in fact, I strongly prefer this behavior and am planning to implement it in D when we get the FQN import. (news://news.digitalmars.com:119/e8r8tt$10cf$3@digitaldaemon.com)
>>>
>>> The one problem with that may be compilation speed. I suspect that a big part of  Java's compile-time and load-time problems are because of all the symbol loading it has to do for a typical class path to enable things like automatic FQN availability. At the command line, the C# compiler actually isn't that fast either for small programs, but in the IDE it seems fast because all this stuff is pre-loaded.
>>
>> I don't think it would affect compilation speed at all. Stuff only needs to be looked up when referenced, and if referenced, it needs to be imported anyway.
>>
> 
> I don't think that is correct for the reference compiler, because Walter's 'static import' proposal still imported the entire module (probably because the way the compiler works now is to 'load' an entire imported module, IIRC).
> 

I should add that I hope it doesn't effect compilation speed much if any and that could be the case, just that I don't think your reason for that is not the way things work now (again, IIRC).

>> As for slowness of Java compilation, I'd say the biggest speed killer is the fact that the compiler is written in Java itself - Java is the least compiler-friendly language I know.. D is, of course, the best (imho).
>>
>>
>> xs0

In article <44B409E6.5060602@nospam.org>, Georg Wrede says...
>
>Walter Bright wrote:
>> xs0 wrote:
>>> OT: if you'll be changing the import system, _PLEASE_ make private imports the default.
>> 
>> 
>> It's too late for that, sorry.
>
>AAARRGGGHHHHH!!!!!
>
>I've taken it for granted this was implicitly agreed to be fixed for months ago.
>
>> 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.
>
>Importing is conceptually distinct enough, so nobody would even notice this "inconsistency".
>
>Please reconsider.
>
>(As noted earlier, broken code, in this case, is easily fixed with a global replace of "import" to "public import".)

I'm curious...

Q1: How many D users out there are *opposed* to imports being private by default?  Even if it requires everyone to change their code?

Q2: How many D users out there are *opposed* to imports being "static" by default?  Even if it requires fixing the imports in every D source file everywhere?

All I've heard in this discussion is proponents for these two changes, with the exception of Walter, of course.

Maybe it's time for some sort of strawman -1/0/+1 vote just to see where people lie.  From were I sit it seems like Walter is the only one opposed to these changes, mainly because he doesn't want to break people's code.  But those same people he's trying to protect seem to be saying "break our code, please!"  Are the teeming fans of the status quo just being quiet, letting Walter duke it out for them?

--Bill