Bill Baxter wrote:
[...]
> 
> 
> 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?

+1

For this change, wont break most of my code, it's mostly private already.

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

+~.5

Not opposed, maybe for. Throw in the sugar for aliasing and I'm in.

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

Bill Baxter wrote:
> 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
> 
> 

I've now written a library for D with about a dozen source files and somewhere between one and two thousand lines of code (most of it generated, but even so). If D's import semantics are improved, I do not care a whit if it breaks every single module I've written. I'm more than willing to change to a new system.

Of course, I'm a relative newcomer to the language, and Pyd is my only project in it of any size.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

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

Hmm, we were talking about the possibility of implicit importing when using FQNs (I think ;)

But it's the same - whatever causes an import (current import, static import, implicit import by FQN, single member import), the processing of a module takes about the same time, because it's basically doing the same thing in every case.. OK, perhaps an implicit import would need a few file accesses to determine which part of the FQN is the actual module/file, but in the grand scheme of things, that should take a negligible amount of time...

Hmm.. considering that imports can be placed anywhere and module names aren't allowed to conflict with anything, it should be quite simple to support "auto-static-importing" on encountering an unknown FQN.. That would allow the following without any new syntax at all:

alias some.module.name smn; // imports and renames a whole module
alias some.module.name.Class smnClass; // imports a single member

std.stdio.writefln("I just need this function from stdio");


xs0

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

+1, as the common case would become the default

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

-1, as the uncommon case would become the default ;) But I'd definitely support implicit private static importing (see my previous post)


xs0

On Tue, 11 Jul 2006 23:47:27 +0000 (UTC), Bill Baxter wrote:

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

I am *not opposed* to the default import being private. It will not break
my code as I already explicitly use private anyway. But even if it did, I'd
have no issue with updating my code to fall in line with better coding
practices such as this proposal.

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

I am *opposed* to the default import being 'static'. This would add a coding burden to writers and make reading code harder, as every imported module member would need to be qualified thus making more clutter in the source code. There may also be the need for a '!static' qualifier to allow coders to override the default behaviour.

I am *not opposed* to allowing coders to use 'static import' if they so choose to, but don't make it the default.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
12/07/2006 10:23:34 AM

xs0 wrote:
>>>> 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).
> 
> Hmm, we were talking about the possibility of implicit importing when using FQNs (I think ;)
> 
> But it's the same - whatever causes an import (current import, static import, implicit import by FQN, single member import), the processing of a module takes about the same time, because it's basically doing the same thing in every case.. OK, perhaps an implicit import would need a few file accesses to determine which part of the FQN is the actual module/file, but in the grand scheme of things, that should take a negligible amount of time...
> 
> Hmm.. considering that imports can be placed anywhere and module names aren't allowed to conflict with anything, it should be quite simple to support "auto-static-importing" on encountering an unknown FQN.. That would allow the following without any new syntax at all:
> 
> alias some.module.name smn; // imports and renames a whole module
> alias some.module.name.Class smnClass; // imports a single member
> 
> std.stdio.writefln("I just need this function from stdio");
> 
> 
> xs0
This would bee useful espesialy for quick things like writefln and similar. (if we got this i would probably stop using printf)

On Tue, 11 Jul 2006 23:47:27 +0000 (UTC), Bill Baxter <Bill_member@pathlink.com> wrote:
> Q1: How many D users out there are *opposed* to imports being private by
> default?  Even if it requires everyone to change their code?

+1 .. but I don't have a large body of code to 'fix'

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

By "static" do you mean:

import std.stdio;
writefln("Hello World");           //error
std.stdio.writefln("Hello World"); //ok

If so, -1, I don't like this. I like D's import into 2ndary namespace and lookup mechanism as a default. I dont like using FQN unless I have to, to disambiguate, and even then I'd prefer the 'as' solution to import into a shorter namespace.

There seems to me to only be a minor difference in functionality between..

import std.stdio;
alias std.stdio io;

writefln("");    //ok
io.writefln(""); //ok

and..

import std.stdio as io;

writefln("");    //error
io.writefln(""); //ok

in that the latter syntax allows the compiler to _not_ import into the 2ndary namespace and _instead_ into the named one, instead of doing both, which is what appears does/will happen using 'alias'. I prefer this.

Regan

Regan Heath wrote:

> There seems to me to only be a minor difference in functionality between..
> 
> import std.stdio;
> alias std.stdio io;
> 
> writefln("");    //ok
> io.writefln(""); //ok
> 
> and..
> 
> import std.stdio as io;
> 
> writefln("");    //error
> io.writefln(""); //ok
> 
> in that the latter syntax allows the compiler to _not_ import into the  2ndary namespace and _instead_ into the named one, instead of doing both,  which is what appears does/will happen using 'alias'. I prefer this.

Exactly!

And this is *very important*.

Don Clugston wrote:
> Just Pascal, and I never liked it.

I used to love Pascal. But that probably was because it (Turbo Pascal) was the only decent language available on micros before the IBM PC came out. Before that I only had used Fortran on large computers and various Microsoft Basics, Ron Cain's Tiny C and ASM on micros.

I still have a sweet spot for Borland and their Pascal (later called Delphi). But "standard Pascal", as the Wirth-book implementations used to call themselves, boy were they a pain to use! No wonder so many university students haven't touched anything Pascal like since then.

> <rant> It seemed to go out of its way to make pointers difficult to understand. Plus, the first line of code was the "program" statement, which didn't actually do anything, and the last was an almost invisible fullstop. This was supposed to be a good teaching language? </rant>

I used to wonder about this (redundant) "program" statement, too. Turns out it existed only because at the time it was the norm to study, comment and discuss the code of a program -- in a context physically removed from any data processing equipment.

That is, every piece of code used to get printed on fanfold paper, and then jointly reviewed by programmers, who then wrote comments and edits in ballpoint on the listing. Hadn't the "program" statement been there, then nobody would have known _which_ program they are studying!

The dot at the end was for the same purpose: you could check if this was the end, or if you should expect more pages. Broken fanfolds or loose-leaf listings simply made this an essential feature.

Contrary to common belief, neither of these were ever there for language teaching needs.

On Wed, 12 Jul 2006 09:25:50 +0300, Georg Wrede wrote:

> Regan Heath wrote:
>> 
>> import std.stdio as io;
>> 
>> writefln("");    //error
>> io.writefln(""); //ok
>> 
>> in that this syntax allows the compiler to _not_ import into the 2ndary namespace and _instead_ into the named one, instead of doing both,  which is what appears does/will happen using 'alias'. I prefer this.
> 
> Exactly!
> 
> And this is *very important*.

Why?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
12/07/2006 4:50:47 PM