www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Historical language survey

reply kris <foo bar.com> writes:
Just for fun, how many folks here have hands-on experience with any of 
the following languages?

Algol
Pascal
BCPL
Ada
Modula
Simula
Jul 06 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Do you mean as in "I was there when the language was invented and was 
among the first to play with it"?
or as in "Yeah .. I've coded in this langauge"?
Jul 06 2006
parent kris <foo bar.com> writes:
Hasan Aljudy wrote:

 
 
 kris wrote:
 

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?

 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


 
 
 Do you mean as in "I was there when the language was invented and was 
 among the first to play with it"?
 or as in "Yeah .. I've coded in this langauge"?


hehe ... the latter: "I've coded in X, Y and/or Z"
Jul 06 2006
prev sibling next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
 Pascal
 BCPL


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
7/07/2006 1:06:23 PM
Jul 06 2006
prev sibling next sibling parent Brad Anderson <brad dsource.org> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Pascal
Jul 06 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Pascal
Jul 06 2006
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Mostly just played with these:

Pascal
Modula 2
Modula 3
Ada
Jul 06 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Some Pascal professionally, that is if you'd consider the Borland/Delphi 
flavor "real" Pascal (I've read people who do not).
Jul 06 2006
prev sibling next sibling parent Justin C Calvarese <technocrat7 gmail.com> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Just Pascal.

I took a Pascal class back during jr. high school. I even bought Turbo 
Pascal 5.5 and upgraded to 6.0 when it came out.

-- 
jcc7
Jul 06 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Pascal .. and I really hated it. It's so wordy, so hard to maintain/debug.
I couldn't debug a doubly linked list with it for crying out loud!
Jul 07 2006
prev sibling next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
kris wrote:


 Just for fun, how many folks here have hands-on experience with any of the
 following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Only Pascal from this list.

(and also have some experience with QBasic, Visual Basic and Fortran)


-- 
AKhropov
Jul 07 2006
parent Carlos Santander <csantander619 gmail.com> writes:
Andrei Khropov escribió:

 kris wrote:
 

 Just for fun, how many folks here have hands-on experience with any of the
 following languages?

 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


 
 Only Pascal from this list.
 
 (and also have some experience with QBasic, Visual Basic and Fortran)
 
 


Same here, but I did a lot more Delphi than Pascal.

-- 
Carlos Santander Bernal
Jul 07 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Just Pascal, and I never liked it.
<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>

The only languages that I was ever excited about were Z-80 assembler 
(the first programming language I ever learned), Forth, Ansi C, C++, and D.
Jul 07 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:

 Just Pascal, and I never liked it.
 <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 liked Pascal until I tried to write useful programs in it (this was 
with Pascal implemented according to Wirth's book). It seems I spent all 
my development time fighting the compiler. The language semantics locked 
everything up so tight there was no way to get things done.

Then I read K+R, and it was like the light coming on. The language let 
me do what I want (casting is the magic ingredient). Despite using early 
very buggy C compilers, I spent my time working on my algorithms rather 
than fighting the compiler.

Pascal vendors noticed the exodus to C, and added a whole boatload of 
C-like extensions to Pascal to make it a usable. By then, though, it was 
too late to interest me; I never looked at Pascal again. (The other 
problem with all those extensions is every vendor did them differently, 
making Pascal probably the most non-portable language in existence 
because you *had* to use the extensions.)

Pascal basically missed its market window.
Jul 07 2006
parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 Don Clugston wrote:
 

 Just Pascal, and I never liked it.
 <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 liked Pascal until I tried to write useful programs in it (this was 
 with Pascal implemented according to Wirth's book). It seems I spent all 
 my development time fighting the compiler. The language semantics locked 
 everything up so tight there was no way to get things done.
 
 Then I read K+R, and it was like the light coming on. The language let 
 me do what I want (casting is the magic ingredient). Despite using early 
 very buggy C compilers, I spent my time working on my algorithms rather 
 than fighting the compiler.
 
 Pascal vendors noticed the exodus to C, and added a whole boatload of 
 C-like extensions to Pascal to make it a usable. By then, though, it was 
 too late to interest me; I never looked at Pascal again. (The other 
 problem with all those extensions is every vendor did them differently, 
 making Pascal probably the most non-portable language in existence 
 because you *had* to use the extensions.)
 


Eh? We're talking about the language according the Wirth here (as Walter 
notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal 
was designed *solely* as an educational tool, for /teaching structured 
programming/ ... the syntax and design was never intended as a solution 
for general-purpose systems programming. It's silly to compare it to C



 Pascal basically missed its market window.


Pascal became the de-facto language of choice within teaching 
establishments; much of the western CS undergraduate courses became 
oriented toward Pascal. The UCSD p-system became the most advanced 
software teaching tool in existance. I'd say Pascal hit its "market 
window" with extreme accuracy. As would most others who were around at 
the time.

If you want to talk about languages intended for systems-programming, 
perhaps you should compare to Modula-2 and Modula-3 instead. Now there's 
a great language that missed its "market window" and/or opportunity.

Interesting to note that D is basically a Modula-3 clone, using C-like 
syntax instead and adding some more op-overloading. Perhaps D could 
adopt the more advanced 'import' capabilities from Modula-3 also? Back 
in the dark ages, they understood such things rather well ... the design 
in Modula-3 allows one to extend original, imported modules without fear 
of breaking the code that imports them. What a concept <g>

In fact, here's an NG post from almost 5 years ago: 
http://www.digitalmars.com/d/archives/94.html
Jul 07 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 Eh? We're talking about the language according the Wirth here (as Walter 
 notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal 
 was designed *solely* as an educational tool, for /teaching structured 
 programming/ ... the syntax and design was never intended as a solution 
 for general-purpose systems programming. It's silly to compare it to C


Intended or not, the pascal compiler vendors of the time certainly 
positioned it as a general purpose programming language, and often it 
was the only choice on a platform other than Fortran, Basic, or assembler.



 Interesting to note that D is basically a Modula-3 clone, using C-like 
 syntax instead and adding some more op-overloading. Perhaps D could 
 adopt the more advanced 'import' capabilities from Modula-3 also? Back 
 in the dark ages, they understood such things rather well ... the design 
 in Modula-3 allows one to extend original, imported modules without fear 
 of breaking the code that imports them. What a concept <g>
 
 In fact, here's an NG post from almost 5 years ago: 
 http://www.digitalmars.com/d/archives/94.html


And I still don't know anything about M3 <g>. But being able to extend 
imports without breaking users can easily be done with some variation on 
the PIMPL technique or interfaces.
Jul 07 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 And I still don't know anything about M3 <g>. But being able to extend 
 imports without breaking users can easily be done with some variation on 
 the PIMPL technique or interfaces.


But PIMPL only works if combined with header files, and it shouldn't be 
necessary to resort to this just to avoid symbol collisions with 
implementation-level stuff.  I do think it's a useful tool when complete 
implementation hiding is necessary for business reasons, but not as a 
general tool to work around what feels like a language issue.


Sean
Jul 07 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 And I still don't know anything about M3 <g>. But being able to extend 
 imports without breaking users can easily be done with some variation 
 on the PIMPL technique or interfaces.


 
 But PIMPL only works if combined with header files, and it shouldn't be 
 necessary to resort to this just to avoid symbol collisions with 
 implementation-level stuff.  I do think it's a useful tool when complete 
 implementation hiding is necessary for business reasons, but not as a 
 general tool to work around what feels like a language issue.


It isn't to avoid symbol collisions, it's to make the user of the class 
immune to adding new members to the implementation of the class.
Jul 07 2006
parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 And I still don't know anything about M3 <g>. But being able to 
 extend imports without breaking users can easily be done with some 
 variation on the PIMPL technique or interfaces.


 But PIMPL only works if combined with header files, and it shouldn't 
 be necessary to resort to this just to avoid symbol collisions with 
 implementation-level stuff.  I do think it's a useful tool when 
 complete implementation hiding is necessary for business reasons, but 
 not as a general tool to work around what feels like a language issue.


 
 It isn't to avoid symbol collisions, it's to make the user of the class 
 immune to adding new members to the implementation of the class.


Ah, my mistake then.  I confused what you were saying with my comment on 
the D import rules.


Sean
Jul 07 2006
prev sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:


 And I still don't know anything about M3 <g>. But being able to extend 
 imports without breaking users can easily be done with some variation on 
 the PIMPL technique or interfaces.


I think you may have missed the point there? It's not about interfaces:

D imports an entire module, into the current namespace (or some 
variation upon that). This means that any additions to the original 
module have to be aware of the namespace usage of *any* module that 
imports the original. Otherwise, a namespace collision will occur and 
the combination will fail to compile. M3 import explicitly from each 
module instead ~ you can't have such a collision. The value of that is 
just as solid today as it was in 1989.

One might argue that with D, one should create new modules instead of 
extending existing ones? That's a fair point until you consider that the 
module namespace is limited to one file, and the 'friend' aspect is 
limited to one module (private attributes being visible within the one 
module). Thus, D suffers this problem in a notable manner.

I forget whether M3 supports importing into a distinct namespace or not 
--- the "import x.y.z. as foo;" syntax -- but that can alleviate related 
problems, and would help resolve the current D namespace conflicts that 
are quite prevalant?
Jul 07 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 D imports an entire module, into the current namespace (or some 
 variation upon that). This means that any additions to the original 
 module have to be aware of the namespace usage of *any* module that 
 imports the original. Otherwise, a namespace collision will occur and 
 the combination will fail to compile. M3 import explicitly from each 
 module instead ~ you can't have such a collision. The value of that is 
 just as solid today as it was in 1989.
 
 One might argue that with D, one should create new modules instead of 
 extending existing ones? That's a fair point until you consider that the 
 module namespace is limited to one file, and the 'friend' aspect is 
 limited to one module (private attributes being visible within the one 
 module). Thus, D suffers this problem in a notable manner.
 
 I forget whether M3 supports importing into a distinct namespace or not 
 --- the "import x.y.z. as foo;" syntax -- but that can alleviate related 
 problems, and would help resolve the current D namespace conflicts that 
 are quite prevalant?


import namespaces are second class citizens in D - they are easily 
overridden by using aliases or fully qualified lookups:

import a;	// defines foo()
import b;	// defines foo()

foo();		// ambiguous
a.foo();	// doesn't matter if there's a b.foo
b.foo();	// works

alias a.foo foo;
foo();		// works

As for import x.y.z. as foo;, you can do:

alias x.y.z foo;
foo.bar();

alias x.y abc;
abc.x.bar();

alias x def;
def.y.z.bar();

The alias works at any level you choose to make it. Alias can be used to 
'import' any name into the current namespace, making it first class.

The second class lookup capability is to make it easier to write quick 
and dirty programs. Aliases or fully qualified names should be used when 
writing large, complex apps. Think of it like using private - you 
wouldn't bother with it for small or throwaway programs, but you 
wouldn't think of not using it for long lived or complex apps.
Jul 07 2006
next sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:
 

 D imports an entire module, into the current namespace (or some 
 variation upon that). This means that any additions to the original 
 module have to be aware of the namespace usage of *any* module that 
 imports the original. Otherwise, a namespace collision will occur and 
 the combination will fail to compile. M3 import explicitly from each 
 module instead ~ you can't have such a collision. The value of that is 
 just as solid today as it was in 1989.

 One might argue that with D, one should create new modules instead of 
 extending existing ones? That's a fair point until you consider that 
 the module namespace is limited to one file, and the 'friend' aspect 
 is limited to one module (private attributes being visible within the 
 one module). Thus, D suffers this problem in a notable manner.

 I forget whether M3 supports importing into a distinct namespace or 
 not --- the "import x.y.z. as foo;" syntax -- but that can alleviate 
 related problems, and would help resolve the current D namespace 
 conflicts that are quite prevalant?


 
 
 import namespaces are second class citizens in D - they are easily 
 overridden by using aliases or fully qualified lookups:
 
 import a;    // defines foo()
 import b;    // defines foo()
 
 foo();        // ambiguous
 a.foo();    // doesn't matter if there's a b.foo
 b.foo();    // works
 
 alias a.foo foo;
 foo();        // works
 
 As for import x.y.z. as foo;, you can do:
 
 alias x.y.z foo;
 foo.bar();
 
 alias x.y abc;
 abc.x.bar();
 
 alias x def;
 def.y.z.bar();
 
 The alias works at any level you choose to make it. Alias can be used to 
 'import' any name into the current namespace, making it first class.
 
 The second class lookup capability is to make it easier to write quick 
 and dirty programs. Aliases or fully qualified names should be used when 
 writing large, complex apps. Think of it like using private - you 
 wouldn't bother with it for small or throwaway programs, but you 
 wouldn't think of not using it for long lived or complex apps.



Yes, I'm aware of those various workarounds, but none of them address 
the issue. As I'm sure you're aware of, all of these need to be used at 
the import site ... not in the importee code. This is where the issues 
arise.

What I was getting at is this:

-------------
module importee;

class Foo {}
-------------

and

-------------
module importer;

import importee;

class Bar {}

class Bazooka {}
-------------


now, suppose we later change module importee like so:

-------------
module importee;

class Foo {}

class Bazooka {}
-------------

Now, module importer will not compile. It needs to be re-engineered 
regardless, since no amount of aliasing of the /importee module/ will 
work. This is where a bit of foresight should come into play regarding 
import namespaces and so on (within the D language). There are a number 
of solutions available. It is precicely this kind of re-engineering that 
should be rendered completely unecessary.

The second aspect is the whole alias notion is just too weak to handle 
large-scale development. In other languages, the syntax "import x.y.z as 
foo;" actually does create a unique namespace, achieving two things:

a) there's no other way to refer to x.y.z content other than through the 
"foo." prefix. This eliminates the potential for conflicting names 
across multiple modules, regardless of long-term maintenance in any of 
them. Relying on the D "alias" mechanism for such needs is prone to 
abject failure.

b) alias simply provides an /additional/ means of referring to some 
element. All of the original names are still there, from the entirety of 
the imported module. The potential for name collisions, such as two 
classes called 'Bazooka' is painfully obvious.

The whole concept of long-term and/or large-scale development using D as 
a tool is marred by such problems -- it's not very hard to fix either -- 
perhaps as simple as the "import x.y.z as foo;" syntax, which is quite 
quite different from the concept of alias. I sincerely hope you'll agree 
on that distinction?
Jul 07 2006
parent reply kris <foo bar.com> writes:
to clarify, here's some examples:

--------------
module foo;

import bar;
import wumpus;

extern (C) int printf (char*, ...);

class Bar {char[] toString() {return "foo.Bar";}}

void main()
{
         auto bar = new Bar;
         auto wumpus = new Wumpus;

         printf ("%.*s\n", bar.toString);
         printf ("%.*s\n", wumpus.toString);
}
-------------


-------------
module bar;

class Bar {char[] toString() {return "bar.Bar";}}
-------------


-------------
module wumpus;

class Wumpus {char[] toString() {return "wumpus.Wumpus";}}
-------------


What's interesting here is the lack of conflict between bar.Bar and 
foo.Bar. The compiler ignores the conflicting names and uses foo.Bar 
within main().

Now, assume both modules foo and bar are from different vendors. Module 
bar gets changed at some point to this:

-------------
module bar;

class Bar {char[] toString() {return "bar.Bar";}}

class Wumpus {char[] toString() {return "bar.Wumpus";}}
-------------


The vendor added a Wumpus class to the module. Quite innocent. In this 
case, the program now fails to compile, and the user-code needs to be 
re-engineered. The amount of redundant work may be small, or it may be 
very large. This is simply redundant work ~ it should not be necessary 
at all.

One way to avoid the re-engineering is to use
"import wumpus as ...."
"import bar as ...."

In this case, the instances of Bar and Wumpus must be fully qualified -- 
you can't access them any other way. Thus it would be "auto bar = new 
bar.Bar;", or whatever.

Another approach is to import explicitly, just like Modula-3 does:

import Bar from bar;
import Wumpus from wumpus;

In this case, it's pretty clear than any additions to modules from 
either vendor will not result in re-engineering work. It's also a bit 
closer to the current D model.


Another question is this: why is there no conflict between the two Bar 
declarations in the first case, while there is between the two Wumpus 
instances in the second case? I suspect this is down to where the decl 
actually resides (which module).






kris wrote:

 Walter Bright wrote:
 

 kris wrote:


 D imports an entire module, into the current namespace (or some 
 variation upon that). This means that any additions to the original 
 module have to be aware of the namespace usage of *any* module that 
 imports the original. Otherwise, a namespace collision will occur and 
 the combination will fail to compile. M3 import explicitly from each 
 module instead ~ you can't have such a collision. The value of that 
 is just as solid today as it was in 1989.

 One might argue that with D, one should create new modules instead of 
 extending existing ones? That's a fair point until you consider that 
 the module namespace is limited to one file, and the 'friend' aspect 
 is limited to one module (private attributes being visible within the 
 one module). Thus, D suffers this problem in a notable manner.

 I forget whether M3 supports importing into a distinct namespace or 
 not --- the "import x.y.z. as foo;" syntax -- but that can alleviate 
 related problems, and would help resolve the current D namespace 
 conflicts that are quite prevalant?




 import namespaces are second class citizens in D - they are easily 
 overridden by using aliases or fully qualified lookups:

 import a;    // defines foo()
 import b;    // defines foo()

 foo();        // ambiguous
 a.foo();    // doesn't matter if there's a b.foo
 b.foo();    // works

 alias a.foo foo;
 foo();        // works

 As for import x.y.z. as foo;, you can do:

 alias x.y.z foo;
 foo.bar();

 alias x.y abc;
 abc.x.bar();

 alias x def;
 def.y.z.bar();

 The alias works at any level you choose to make it. Alias can be used 
 to 'import' any name into the current namespace, making it first class.

 The second class lookup capability is to make it easier to write quick 
 and dirty programs. Aliases or fully qualified names should be used 
 when writing large, complex apps. Think of it like using private - you 
 wouldn't bother with it for small or throwaway programs, but you 
 wouldn't think of not using it for long lived or complex apps.


 
 
 
 Yes, I'm aware of those various workarounds, but none of them address 
 the issue. As I'm sure you're aware of, all of these need to be used at 
 the import site ... not in the importee code. This is where the issues 
 arise.
 
 What I was getting at is this:
 
 -------------
 module importee;
 
 class Foo {}
 -------------
 
 and
 
 -------------
 module importer;
 
 import importee;
 
 class Bar {}
 
 class Bazooka {}
 -------------
 
 
 now, suppose we later change module importee like so:
 
 -------------
 module importee;
 
 class Foo {}
 
 class Bazooka {}
 -------------
 
 Now, module importer will not compile. It needs to be re-engineered 
 regardless, since no amount of aliasing of the /importee module/ will 
 work. This is where a bit of foresight should come into play regarding 
 import namespaces and so on (within the D language). There are a number 
 of solutions available. It is precicely this kind of re-engineering that 
 should be rendered completely unecessary.
 
 The second aspect is the whole alias notion is just too weak to handle 
 large-scale development. In other languages, the syntax "import x.y.z as 
 foo;" actually does create a unique namespace, achieving two things:
 
 a) there's no other way to refer to x.y.z content other than through the 
 "foo." prefix. This eliminates the potential for conflicting names 
 across multiple modules, regardless of long-term maintenance in any of 
 them. Relying on the D "alias" mechanism for such needs is prone to 
 abject failure.
 
 b) alias simply provides an /additional/ means of referring to some 
 element. All of the original names are still there, from the entirety of 
 the imported module. The potential for name collisions, such as two 
 classes called 'Bazooka' is painfully obvious.
 
 The whole concept of long-term and/or large-scale development using D as 
 a tool is marred by such problems -- it's not very hard to fix either -- 
 perhaps as simple as the "import x.y.z as foo;" syntax, which is quite 
 quite different from the concept of alias. I sincerely hope you'll agree 
 on that distinction?
Jul 07 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
kris wrote:

 to clarify, here's some examples:
 
 --------------
 module foo;
 
 import bar;
 import wumpus;
 
 extern (C) int printf (char*, ...);
 
 class Bar {char[] toString() {return "foo.Bar";}}
 
 void main()
 {
         auto bar = new Bar;
         auto wumpus = new Wumpus;
 
         printf ("%.*s\n", bar.toString);
         printf ("%.*s\n", wumpus.toString);
 }
 -------------
 
 
 -------------
 module bar;
 
 class Bar {char[] toString() {return "bar.Bar";}}
 -------------
 
 
 -------------
 module wumpus;
 
 class Wumpus {char[] toString() {return "wumpus.Wumpus";}}
 -------------
 
 
 What's interesting here is the lack of conflict between bar.Bar and 
 foo.Bar. The compiler ignores the conflicting names and uses foo.Bar 
 within main().
 
 Now, assume both modules foo and bar are from different vendors.


You meant modules wumpus and bar :-)


 Module bar gets changed at some point to this:
 
 -------------
 module bar;
 
 class Bar {char[] toString() {return "bar.Bar";}}
 
 class Wumpus {char[] toString() {return "bar.Wumpus";}}
 -------------
 
 
 The vendor added a Wumpus class to the module. Quite innocent. In this 
 case, the program now fails to compile, and the user-code needs to be 
 re-engineered. The amount of redundant work may be small, or it may be 
 very large. This is simply redundant work ~ it should not be necessary 
 at all.
 
 One way to avoid the re-engineering is to use
 "import wumpus as ...."
 "import bar as ...."
 
 In this case, the instances of Bar and Wumpus must be fully qualified -- 
 you can't access them any other way. Thus it would be "auto bar = new 
 bar.Bar;", or whatever.


This would be the alternate interpretation of the "issue of whether the 
contents of x.y.z are visible without the 'foo' qualifier" in my last 
post.  Personally, I think either interpretation would work as I believe 
collisions only occur when a lookup is being processed, not simply 
because the symbols happen to exist in the various modules, but your 
method would help the user avoid accidental non-qualified use of 
imported symbols.


 Another approach is to import explicitly, just like Modula-3 does:
 
 import Bar from bar;
 import Wumpus from wumpus;
 
 In this case, it's pretty clear than any additions to modules from 
 either vendor will not result in re-engineering work. It's also a bit 
 closer to the current D model.


I like this idea irrespective of the other issues being discussed.  For 
example, one irritating issue for implementing Posix headers is that 
they are all inter-dependent, and each header is often required to 
expose particular symbols from other headers.  The only way to do this 
now in D is to publicly import one module entirely into the other 
module, and finer-grained control would be far nicer.  Unfortunately, 
alias can't be used to resolve this issue:

     module A;

     alias foo bar;

----------

     module B;

     private import A;

     alias A.bar bar;

because it causes multiple definition errors.


 Another question is this: why is there no conflict between the two Bar 
 declarations in the first case, while there is between the two Wumpus 
 instances in the second case? I suspect this is down to where the decl 
 actually resides (which module).


It's because of what Walter said about import namespaces being 
second-class citizens in D.  Any symbol in the current module 
automatically has priority over a same-named symbol in an import module. 
  If you want to use the import symbol instead you must either fully 
qualify it or alias it locally to put it on equal footing with the other 
local symbols.


Sean
Jul 07 2006
next sibling parent kris <foo bar.com> writes:
Sean Kelly wrote:

 kris wrote:
 

 to clarify, here's some examples:

 --------------
 module foo;

 import bar;
 import wumpus;

 extern (C) int printf (char*, ...);

 class Bar {char[] toString() {return "foo.Bar";}}

 void main()
 {
         auto bar = new Bar;
         auto wumpus = new Wumpus;

         printf ("%.*s\n", bar.toString);
         printf ("%.*s\n", wumpus.toString);
 }
 -------------


 -------------
 module bar;

 class Bar {char[] toString() {return "bar.Bar";}}
 -------------


 -------------
 module wumpus;

 class Wumpus {char[] toString() {return "wumpus.Wumpus";}}
 -------------


 What's interesting here is the lack of conflict between bar.Bar and 
 foo.Bar. The compiler ignores the conflicting names and uses foo.Bar 
 within main().

 Now, assume both modules foo and bar are from different vendors.


 
 
 You meant modules wumpus and bar :-)



Yes, I did ~ thank you




 Module bar gets changed at some point to this:

 -------------
 module bar;

 class Bar {char[] toString() {return "bar.Bar";}}

 class Wumpus {char[] toString() {return "bar.Wumpus";}}
 -------------


 The vendor added a Wumpus class to the module. Quite innocent. In this 
 case, the program now fails to compile, and the user-code needs to be 
 re-engineered. The amount of redundant work may be small, or it may be 
 very large. This is simply redundant work ~ it should not be necessary 
 at all.

 One way to avoid the re-engineering is to use
 "import wumpus as ...."
 "import bar as ...."

 In this case, the instances of Bar and Wumpus must be fully qualified 
 -- you can't access them any other way. Thus it would be "auto bar = 
 new bar.Bar;", or whatever.


 
 
 This would be the alternate interpretation of the "issue of whether the 
 contents of x.y.z are visible without the 'foo' qualifier" in my last 
 post.  Personally, I think either interpretation would work as I believe 
 collisions only occur when a lookup is being processed, not simply 
 because the symbols happen to exist in the various modules, but your 
 method would help the user avoid accidental non-qualified use of 
 imported symbols.
 

 Another approach is to import explicitly, just like Modula-3 does:

 import Bar from bar;
 import Wumpus from wumpus;

 In this case, it's pretty clear than any additions to modules from 
 either vendor will not result in re-engineering work. It's also a bit 
 closer to the current D model.


 
 
 I like this idea irrespective of the other issues being discussed.  



Me too. It appears to be fairly immune to the kind of issues discussed 
here, and could be thought of as purely a refinement (or focusing) of 
the current approach to import.



 For 
 example, one irritating issue for implementing Posix headers is that 
 they are all inter-dependent, and each header is often required to 
 expose particular symbols from other headers.  The only way to do this 
 now in D is to publicly import one module entirely into the other 
 module, and finer-grained control would be far nicer.  Unfortunately, 
 alias can't be used to resolve this issue:
 
     module A;
 
     alias foo bar;
 
 ----------
 
     module B;
 
     private import A;
 
     alias A.bar bar;
 
 because it causes multiple definition errors.
 

 Another question is this: why is there no conflict between the two Bar 
 declarations in the first case, while there is between the two Wumpus 
 instances in the second case? I suspect this is down to where the decl 
 actually resides (which module).


 
 
 It's because of what Walter said about import namespaces being 
 second-class citizens in D.  Any symbol in the current module 
 automatically has priority over a same-named symbol in an import module. 
  If you want to use the import symbol instead you must either fully 
 qualify it or alias it locally to put it on equal footing with the other 
 local symbols.



OK; thanks.
Jul 07 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 This would be the alternate interpretation of the "issue of whether the 
 contents of x.y.z are visible without the 'foo' qualifier" in my last 
 post.  Personally, I think either interpretation would work as I believe 
 collisions only occur when a lookup is being processed, not simply 
 because the symbols happen to exist in the various modules,


That is correct.
Jul 07 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 to clarify, here's some examples:
 
 --------------
 module foo;
 
 import bar;
 import wumpus;
 
 extern (C) int printf (char*, ...);
 
 class Bar {char[] toString() {return "foo.Bar";}}
 
 void main()
 {
         auto bar = new Bar;
         auto wumpus = new Wumpus;
 
         printf ("%.*s\n", bar.toString);
         printf ("%.*s\n", wumpus.toString);
 }
 -------------
 
 
 -------------
 module bar;
 
 class Bar {char[] toString() {return "bar.Bar";}}
 -------------
 
 
 -------------
 module wumpus;
 
 class Wumpus {char[] toString() {return "wumpus.Wumpus";}}
 -------------
 
 
 What's interesting here is the lack of conflict between bar.Bar and 
 foo.Bar. The compiler ignores the conflicting names and uses foo.Bar 
 within main().
 
 Now, assume both modules foo and bar are from different vendors. Module 
 bar gets changed at some point to this:
 
 -------------
 module bar;
 
 class Bar {char[] toString() {return "bar.Bar";}}
 
 class Wumpus {char[] toString() {return "bar.Wumpus";}}
 -------------
 
 
 The vendor added a Wumpus class to the module. Quite innocent. In this 
 case, the program now fails to compile, and the user-code needs to be 
 re-engineered. The amount of redundant work may be small, or it may be 
 very large. This is simply redundant work ~ it should not be necessary 
 at all.
 
 One way to avoid the re-engineering is to use
 "import wumpus as ...."
 "import bar as ...."
 
 In this case, the instances of Bar and Wumpus must be fully qualified -- 
 you can't access them any other way. Thus it would be "auto bar = new 
 bar.Bar;", or whatever.
 
 Another approach is to import explicitly, just like Modula-3 does:
 
 import Bar from bar;
 import Wumpus from wumpus;
 
 In this case, it's pretty clear than any additions to modules from 
 either vendor will not result in re-engineering work. It's also a bit 
 closer to the current D model.
 
 
 Another question is this: why is there no conflict between the two Bar 
 declarations in the first case, while there is between the two Wumpus 
 instances in the second case? I suspect this is down to where the decl 
 actually resides (which module).
 
 
 
 
 
 
 kris wrote:

 Walter Bright wrote:


 kris wrote:


 D imports an entire module, into the current namespace (or some 
 variation upon that). This means that any additions to the original 
 module have to be aware of the namespace usage of *any* module that 
 imports the original. Otherwise, a namespace collision will occur 
 and the combination will fail to compile. M3 import explicitly from 
 each module instead ~ you can't have such a collision. The value of 
 that is just as solid today as it was in 1989.

 One might argue that with D, one should create new modules instead 
 of extending existing ones? That's a fair point until you consider 
 that the module namespace is limited to one file, and the 'friend' 
 aspect is limited to one module (private attributes being visible 
 within the one module). Thus, D suffers this problem in a notable 
 manner.

 I forget whether M3 supports importing into a distinct namespace or 
 not --- the "import x.y.z. as foo;" syntax -- but that can alleviate 
 related problems, and would help resolve the current D namespace 
 conflicts that are quite prevalant?




 import namespaces are second class citizens in D - they are easily 
 overridden by using aliases or fully qualified lookups:

 import a;    // defines foo()
 import b;    // defines foo()

 foo();        // ambiguous
 a.foo();    // doesn't matter if there's a b.foo
 b.foo();    // works

 alias a.foo foo;
 foo();        // works

 As for import x.y.z. as foo;, you can do:

 alias x.y.z foo;
 foo.bar();

 alias x.y abc;
 abc.x.bar();

 alias x def;
 def.y.z.bar();

 The alias works at any level you choose to make it. Alias can be used 
 to 'import' any name into the current namespace, making it first class.

 The second class lookup capability is to make it easier to write 
 quick and dirty programs. Aliases or fully qualified names should be 
 used when writing large, complex apps. Think of it like using private 
 - you wouldn't bother with it for small or throwaway programs, but 
 you wouldn't think of not using it for long lived or complex apps.




 Yes, I'm aware of those various workarounds, but none of them address 
 the issue. As I'm sure you're aware of, all of these need to be used 
 at the import site ... not in the importee code. This is where the 
 issues arise.

 What I was getting at is this:

 -------------
 module importee;

 class Foo {}
 -------------

 and

 -------------
 module importer;

 import importee;

 class Bar {}

 class Bazooka {}
 -------------


 now, suppose we later change module importee like so:

 -------------
 module importee;

 class Foo {}

 class Bazooka {}
 -------------

 Now, module importer will not compile.




Yes, it will, because names in the module being compiled take priority 
over imported names. A conflict only happens if two or more imports 
define the same name.


 The second aspect is the whole alias notion is just too weak to handle 
 large-scale development. In other languages, the syntax "import x.y.z 
 as foo;" actually does create a unique namespace, achieving two things:

 a) there's no other way to refer to x.y.z content other than through 
 the "foo." prefix. This eliminates the potential for conflicting names 
 across multiple modules, regardless of long-term maintenance in any of 
 them. Relying on the D "alias" mechanism for such needs is prone to 
 abject failure.




Why is it prone to abject failure? The only thing really necessary is 
that the module names themselves be unique or be in a package with a 
unique name.


 b) alias simply provides an /additional/ means of referring to some 
 element. All of the original names are still there, from the entirety 
 of the imported module. The potential for name collisions, such as two 
 classes called 'Bazooka' is painfully obvious.




Not if you use either fully qualified names when importing, or you use 
an alias to pick which Bazooka you want.


 The whole concept of long-term and/or large-scale development using D 
 as a tool is marred by such problems -- it's not very hard to fix 
 either -- perhaps as simple as the "import x.y.z as foo;" syntax, 
 which is quite quite different from the concept of alias. I sincerely 
 hope you'll agree on that distinction?




I'm not sure it's that different. But I also think (because of the 
example above) there's a misunderstanding about how import name lookups 
work.
Jul 07 2006
parent reply kris <foo bar.com> writes:
Walter;

I added compilable code at the top of the post here, in a genuine 
attempt to show you where the current design has a weakness. Yet, you 
ignored those clarifications entirely. Focusing instead on pre-clarified 
observations, which could be considered somewhat ambiguous, doesn't help 
much at all :(

The code provided illustrates the weakness quite well. I do hope you'll 
run the example provided, and address that instead?

Please see below:



Walter Bright wrote:

 kris wrote:
 

 to clarify, here's some examples:

 --------------
 module foo;

 import bar;
 import wumpus;

 extern (C) int printf (char*, ...);

 class Bar {char[] toString() {return "foo.Bar";}}

 void main()
 {
         auto bar = new Bar;
         auto wumpus = new Wumpus;

         printf ("%.*s\n", bar.toString);
         printf ("%.*s\n", wumpus.toString);
 }
 -------------


 -------------
 module bar;

 class Bar {char[] toString() {return "bar.Bar";}}
 -------------


 -------------
 module wumpus;

 class Wumpus {char[] toString() {return "wumpus.Wumpus";}}
 -------------


 What's interesting here is the lack of conflict between bar.Bar and 
 foo.Bar. The compiler ignores the conflicting names and uses foo.Bar 
 within main().

 Now, assume both modules wumpus and bar are from different vendors. 
 Module bar gets changed at some point to this:

 -------------
 module bar;

 class Bar {char[] toString() {return "bar.Bar";}}

 class Wumpus {char[] toString() {return "bar.Wumpus";}}
 -------------


 The vendor added a Wumpus class to the module. Quite innocent. In this 
 case, the program now fails to compile, and the user-code needs to be 
 re-engineered. The amount of redundant work may be small, or it may be 
 very large. This is simply redundant work ~ it should not be necessary 
 at all.

 One way to avoid the re-engineering is to use
 "import wumpus as ...."
 "import bar as ...."

 In this case, the instances of Bar and Wumpus must be fully qualified 
 -- you can't access them any other way. Thus it would be "auto bar = 
 new bar.Bar;", or whatever.

 Another approach is to import explicitly, just like Modula-3 does:

 import Bar from bar;
 import Wumpus from wumpus;

 In this case, it's pretty clear than any additions to modules from 
 either vendor will not result in re-engineering work. It's also a bit 
 closer to the current D model.


 Another question is this: why is there no conflict between the two Bar 
 declarations in the first case, while there is between the two Wumpus 
 instances in the second case? I suspect this is down to where the decl 
 actually resides (which module).






 kris wrote:


 Walter Bright wrote:


 kris wrote:


 D imports an entire module, into the current namespace (or some 
 variation upon that). This means that any additions to the original 
 module have to be aware of the namespace usage of *any* module that 
 imports the original. Otherwise, a namespace collision will occur 
 and the combination will fail to compile. M3 import explicitly from 
 each module instead ~ you can't have such a collision. The value of 
 that is just as solid today as it was in 1989.

 One might argue that with D, one should create new modules instead 
 of extending existing ones? That's a fair point until you consider 
 that the module namespace is limited to one file, and the 'friend' 
 aspect is limited to one module (private attributes being visible 
 within the one module). Thus, D suffers this problem in a notable 
 manner.

 I forget whether M3 supports importing into a distinct namespace or 
 not --- the "import x.y.z. as foo;" syntax -- but that can 
 alleviate related problems, and would help resolve the current D 
 namespace conflicts that are quite prevalant?





 import namespaces are second class citizens in D - they are easily 
 overridden by using aliases or fully qualified lookups:

 import a;    // defines foo()
 import b;    // defines foo()

 foo();        // ambiguous
 a.foo();    // doesn't matter if there's a b.foo
 b.foo();    // works

 alias a.foo foo;
 foo();        // works

 As for import x.y.z. as foo;, you can do:

 alias x.y.z foo;
 foo.bar();

 alias x.y abc;
 abc.x.bar();

 alias x def;
 def.y.z.bar();

 The alias works at any level you choose to make it. Alias can be 
 used to 'import' any name into the current namespace, making it 
 first class.

 The second class lookup capability is to make it easier to write 
 quick and dirty programs. Aliases or fully qualified names should be 
 used when writing large, complex apps. Think of it like using 
 private - you wouldn't bother with it for small or throwaway 
 programs, but you wouldn't think of not using it for long lived or 
 complex apps.





 Yes, I'm aware of those various workarounds, but none of them address 
 the issue. As I'm sure you're aware of, all of these need to be used 
 at the import site ... not in the importee code. This is where the 
 issues arise.

 What I was getting at is this:

 -------------
 module importee;

 class Foo {}
 -------------

 and

 -------------
 module importer;

 import importee;

 class Bar {}

 class Bazooka {}
 -------------


 now, suppose we later change module importee like so:

 -------------
 module importee;

 class Foo {}

 class Bazooka {}
 -------------

 Now, module importer will not compile.




 
 
 Yes, it will, because names in the module being compiled take priority 
 over imported names. A conflict only happens if two or more imports 
 define the same name.
 

 The second aspect is the whole alias notion is just too weak to 
 handle large-scale development. In other languages, the syntax 
 "import x.y.z as foo;" actually does create a unique namespace, 
 achieving two things:

 a) there's no other way to refer to x.y.z content other than through 
 the "foo." prefix. This eliminates the potential for conflicting 
 names across multiple modules, regardless of long-term maintenance in 
 any of them. Relying on the D "alias" mechanism for such needs is 
 prone to abject failure.




 
 
 Why is it prone to abject failure? The only thing really necessary is 
 that the module names themselves be unique or be in a package with a 
 unique name.


Please see the examples at the top of this post, and those in Sean's 
post also.



 

 b) alias simply provides an /additional/ means of referring to some 
 element. All of the original names are still there, from the entirety 
 of the imported module. The potential for name collisions, such as 
 two classes called 'Bazooka' is painfully obvious.




 
 
 Not if you use either fully qualified names when importing, or you use 
 an alias to pick which Bazooka you want.


The whole point of this particular thread is to avoid needless 
modifications to code which imports other modules; where those /other/ 
modules change over time. It appears that you're thinking purely in 
terms of "I own all the code, and I'll be responsible for all of the 
namespace issues". I sincerely hope we don't have to spell out the 
limitations with such a notion?


 

 The whole concept of long-term and/or large-scale development using D 
 as a tool is marred by such problems -- it's not very hard to fix 
 either -- perhaps as simple as the "import x.y.z as foo;" syntax, 
 which is quite quite different from the concept of alias. I sincerely 
 hope you'll agree on that distinction?




 
 
 I'm not sure it's that different. But I also think (because of the 
 example above) there's a misunderstanding about how import name lookups 
 work.


That's exactly why I added the working code examples at the top of the 
post -- so you could try it out with the compiler, and observe for 
yourself what it does. It demonstrates that the current import handling 
is really quite brittle from a large-scale and/or long-term development 
aspect. Please read the clarifications toward the top of this post.
Jul 07 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 Walter;
 
 I added compilable code at the top of the post here, in a genuine 
 attempt to show you where the current design has a weakness. Yet, you 
 ignored those clarifications entirely. Focusing instead on pre-clarified 
 observations, which could be considered somewhat ambiguous, doesn't help 
 much at all :(
 
 The code provided illustrates the weakness quite well. I do hope you'll 
 run the example provided, and address that instead?


I want to make sure first that all understand how it currently works, 
and that the way it works is neither a bug nor erratic.

The following two suggestions:


 One way to avoid the re-engineering is to use
 "import wumpus as ...."
 "import bar as ...."

 Another approach is to import explicitly, just like Modula-3 does:

 import Bar from bar;
 import Wumpus from wumpus;

 In this case, it's pretty clear than any additions to modules from 
 either vendor will not result in re-engineering work. It's also a bit 
 closer to the current D model.






suggest the onus is on the importer, not the importee.


 Yes, I'm aware of those various workarounds, but none of them 
 address the issue. As I'm sure you're aware of, all of these need to 
 be used at the import site ... not in the importee code. This is 
 where the issues arise.








But the proposed improvements involve changing the importer code.



 Not if you use either fully qualified names when importing, or you use 
 an alias to pick which Bazooka you want.


 
 The whole point of this particular thread is to avoid needless 
 modifications to code which imports other modules; where those /other/ 
 modules change over time.


But the suggestions involve changing the importer code, too. I'm not 
seeing the advantage of that over fully qualifying the references or 
using an alias, both of which will ensure that no future imports will 
cause name collisions.



 That's exactly why I added the working code examples at the top of the 
 post -- so you could try it out with the compiler, and observe for 
 yourself what it does. It demonstrates that the current import handling 
 is really quite brittle from a large-scale and/or long-term development 
 aspect. Please read the clarifications toward the top of this post.


I know exactly how it works, and it's working as designed (I wish to 
emphasize the way it works is as intended - it's not a bug and alias is 
not a workaround). The current module scope overrides any imported 
symbols, and if a symbol is not in the current module scope but is in 
more than one import, an ambiguity error occurs (because all imports 
have equal standing, none is favored over another).

What can be done is something like add a warning whenever a name is 
found using the second-class import lookup, rather than using an alias 
or a fully qualified lookup. Then, you'll be able to easily purge your 
code of any such, and be confident that adding other modules will not 
break your existing code.

What can also be done is extend the import declaration to allow the .'s 
to continue so that specific symbols can be imported.
Jul 07 2006
next sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 What can be done is something like add a warning whenever a name is 
 found using the second-class import lookup, rather than using an alias 
 or a fully qualified lookup. Then, you'll be able to easily purge your 
 code of any such, and be confident that adding other modules will not 
 break your existing code.


I perhaps don't quite follow that completely. But it sounds like you're 
saying all names would have to be fully qualified at all times, unless 
they're declared within the enclosing module? If not, then forgive me 
for not following correctly.

If so, I think that would overly restrictive, and would perhaps 
encourage a slew of aliases just to make things work correctly. I think 
that would be detrimental, since those who wish to write Q&D code would 
find themselves prejudiced against. The "import x.y.z as foo;" syntax 
suggested is purely an option for those who care about ensuring the 
namespaces are fully isolated ~ and is a clean way to do it for an 
entire module as a time. e.g. with the "as" syntax, the following would 
operate without conflict:

---
module a;

int foo() {...}

---
module b;

int foo() {...}

---
module main;

import a;
import b as other;

void main()
{
	foo();       // a.foo
	other.foo()  // b.foo;
}

In this trivial example, you could do the same with an alias. However, 
an alias would /potentially/ be needed for every symbol within module b, 
whereas the "as" handles all of that cleanly. Consider the effort to 
manually alias each symbol from each imported modules that may 
potentially change over time? Import "as" does it cleanly instead.

However, I think this next option is preferable:



 What can also be done is extend the import declaration to allow the .'s 
 to continue so that specific symbols can be imported.


Now that would be great. I believe selective-importing (as an option) 
would be a boon in a number of ways ~ and would resolve this issue quite 
elegantly.

Neither of these would have any effect on existing code, so there's no 
concern over backward compatability. But it could be argued that the 
latter case is notably more explicit, and perhaps avoids an additional 
renaming step within the compiler.
Jul 07 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 Walter Bright wrote:

 What can be done is something like add a warning whenever a name is 
 found using the second-class import lookup, rather than using an alias 
 or a fully qualified lookup. Then, you'll be able to easily purge your 
 code of any such, and be confident that adding other modules will not 
 break your existing code.


 
 I perhaps don't quite follow that completely. But it sounds like you're 
 saying all names would have to be fully qualified at all times, unless 
 they're declared within the enclosing module?


Yes.


 ---
 module a;
 
 int foo() {...}
 
 ---
 module b;
 
 int foo() {...}
 
 ---
 module main;
 
 import a;
 import b as other;
 
 void main()
 {
     foo();       // a.foo
     other.foo()  // b.foo;
 }
 
 In this trivial example, you could do the same with an alias. However, 
 an alias would /potentially/ be needed for every symbol within module b, 
 whereas the "as" handles all of that cleanly. Consider the effort to 
 manually alias each symbol from each imported modules that may 
 potentially change over time? Import "as" does it cleanly instead.


What I don't like about that proposal is the same reason you didn't like 
the warning proposal above - you'd be forced to fully qualify all 
references to names within b.


 However, I think this next option is preferable:
 
 

 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.


 
 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue quite 
 elegantly.


I like this one better, too.



 Neither of these would have any effect on existing code, so there's no 
 concern over backward compatability. But it could be argued that the 
 latter case is notably more explicit, and perhaps avoids an additional 
 renaming step within the compiler.
Jul 07 2006
next sibling parent kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:
 

 Walter Bright wrote:


 What can be done is something like add a warning whenever a name is 
 found using the second-class import lookup, rather than using an 
 alias or a fully qualified lookup. Then, you'll be able to easily 
 purge your code of any such, and be confident that adding other 
 modules will not break your existing code.



 I perhaps don't quite follow that completely. But it sounds like 
 you're saying all names would have to be fully qualified at all times, 
 unless they're declared within the enclosing module?


 
 
 Yes.
 

 ---
 module a;

 int foo() {...}

 ---
 module b;

 int foo() {...}

 ---
 module main;

 import a;
 import b as other;

 void main()
 {
     foo();       // a.foo
     other.foo()  // b.foo;
 }

 In this trivial example, you could do the same with an alias. However, 
 an alias would /potentially/ be needed for every symbol within module 
 b, whereas the "as" handles all of that cleanly. Consider the effort 
 to manually alias each symbol from each imported modules that may 
 potentially change over time? Import "as" does it cleanly instead.


 
 
 What I don't like about that proposal is the same reason you didn't like 
 the warning proposal above - you'd be forced to fully qualify all 
 references to names within b.
 

 However, I think this next option is preferable:



 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.



 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue 
 quite elegantly.


 
 
 I like this one better, too.



As FatFreddy would have noted, "Well, I'll be dipped in dogshit ..."
Jul 07 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 kris wrote:

 module main;

 import a;
 import b as other;

 void main()
 {
     foo();       // a.foo
     other.foo()  // b.foo;
 }

 In this trivial example, you could do the same with an alias. However, 
 an alias would /potentially/ be needed for every symbol within module 
 b, whereas the "as" handles all of that cleanly. Consider the effort 
 to manually alias each symbol from each imported modules that may 
 potentially change over time? Import "as" does it cleanly instead.


 
 What I don't like about that proposal is the same reason you didn't like 
 the warning proposal above - you'd be forced to fully qualify all 
 references to names within b.


And that's why I suggested it could be syntactic sugar for an alias 
declaration instead, thus making the qualifier optional.  That said, 
it's worth noting that "other" as a user-chosen alias will likely be far 
shorter than the package/module name they represent.  I would much 
rather say "sql.connection" than "some.guys.fancy.sql.connection."


 However, I think this next option is preferable:


 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.


 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue 
 quite elegantly.


 
 I like this one better, too.


Same here.


Sean
Jul 08 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Walter Bright wrote:

 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.


 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue 
 quite elegantly.


 
 I like this one better, too.


There's another way - have a different kind of import declaration, say, 
precede it with static:

	static import foo;

which will make the symbols in foo available, but only if they are 
explicitly qualified. Then one could access bar in foo by either:

	foo.bar();

or:

	alias foo.bar bar;
	bar();

but not:

	bar();	// error, undefined symbol

The advantage of this is it is a bit more flexible and more consistent 
with the way the rest of D lookups work.
Jul 08 2006
next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 18:23:09 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Walter Bright wrote:

 What can also be done is extend the import declaration to allow the  
 .'s to continue so that specific symbols can be imported.


 Now that would be great. I believe selective-importing (as an option)  
 would be a boon in a number of ways ~ and would resolve this issue  
 quite elegantly.


  I like this one better, too.


 There's another way - have a different kind of import declaration, say,  
 precede it with static:

 	static import foo;

 which will make the symbols in foo available, but only if they are  
 explicitly qualified. Then one could access bar in foo by either:

 	foo.bar();

 or:

 	alias foo.bar bar;
 	bar();

 but not:

 	bar();	// error, undefined symbol

 The advantage of this is it is a bit more flexible and more consistent  
 with the way the rest of D lookups work.


Nice. But only if foo.bar is not private. If its private the caller should  
not be able to call it.

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
prev sibling next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <e8nq1e$16r$1 digitaldaemon.com>, Walter Bright says...

Walter Bright wrote:

 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.


 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue 
 quite elegantly.


 
 I like this one better, too.


There's another way - have a different kind of import declaration, say, 
precede it with static:

	static import foo;

which will make the symbols in foo available, but only if they are 
explicitly qualified. Then one could access bar in foo by either:

	foo.bar();

or:

	alias foo.bar bar;
	bar();

but not:

	bar();	// error, undefined symbol

The advantage of this is it is a bit more flexible and more consistent 
with the way the rest of D lookups work.


Er, that really doesn't work at all. Please ignore what I said a few minutes ago
regarding this option (I really should get some sleep instead). 

The problem here is that, for the proposed static imports, everything must be
fully-qualified with the /original import name/, and that's just plain awful for
long import names. The "import as" allows one to give it a nice short name
instead.

And, I still think the selective-import is the superior solution anyway.

(I'd delete my earlier reply, but TBird is doing really wierd things with
messages right now, and is basically hiding all my own posts)
Jul 08 2006
next sibling parent Carlos Santander <csantander619 gmail.com> writes:
Kris escribió:

 In article <e8nq1e$16r$1 digitaldaemon.com>, Walter Bright says...

 Walter Bright wrote:

 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.


 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue 
 quite elegantly.


 I like this one better, too.


 There's another way - have a different kind of import declaration, say, 
 precede it with static:

 	static import foo;

 which will make the symbols in foo available, but only if they are 
 explicitly qualified. Then one could access bar in foo by either:

 	foo.bar();

 or:

 	alias foo.bar bar;
 	bar();

 but not:

 	bar();	// error, undefined symbol

 The advantage of this is it is a bit more flexible and more consistent 
 with the way the rest of D lookups work.


 
 Er, that really doesn't work at all. Please ignore what I said a few minutes
ago
 regarding this option (I really should get some sleep instead). 
 
 The problem here is that, for the proposed static imports, everything must be
 fully-qualified with the /original import name/, and that's just plain awful
for
 long import names. The "import as" allows one to give it a nice short name
 instead.
 


But "static import" + "alias" would give us something closer to "import as"
than 
the current "import" + "alias". Taking Sean previous example, if you have:

module some.guys.fancy.sql;
class connection { ... }

In your module you could do:

static import some.guys.fancy.sql;
alias some.guys.fancy.sql sql;

And you either use "sql.connection" or "some.guys.fancy.sql.connection", but 
connection wouldn't be available in the current namespace.

Now, I know it's more typing, it's two lines when you we could do it in one,
but 
at least it would be an improvement (IMHO).


 And, I still think the selective-import is the superior solution anyway.
 
 (I'd delete my earlier reply, but TBird is doing really wierd things with
 messages right now, and is basically hiding all my own posts)
 
 



-- 
Carlos Santander Bernal
Jul 08 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Kris wrote:

 Er, that really doesn't work at all. Please ignore what I said a few minutes
ago
 regarding this option (I really should get some sleep instead). 
 
 The problem here is that, for the proposed static imports, everything must be
 fully-qualified with the /original import name/, and that's just plain awful
for
 long import names. The "import as" allows one to give it a nice short name
 instead.


Alias also works fine for making substitutes for long, awkward names:

import x.y.mod;
alias x.y.mod t;

x.y.mod.foo();	// works
t.foo();	// also works



 And, I still think the selective-import is the superior solution anyway.


Semantically, it isn't any different. It would even be implemented 
internally using the 'alias' machinery.
Jul 08 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 10:54:03 +1000, Walter Bright  
<newshound digitalmars.com> wrote:



 Alias also works fine for making substitutes for long, awkward names:

 import x.y.mod;
 alias x.y.mod t;

 x.y.mod.foo();	// works
 t.foo();	// also works


Why not join the two ...

   import x.y.mod alias t;

   t.foo();

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Derek Parnell wrote:

 On Sun, 09 Jul 2006 10:54:03 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:
 
 

 Alias also works fine for making substitutes for long, awkward names:

 import x.y.mod;
 alias x.y.mod t;

 x.y.mod.foo();    // works
 t.foo();    // also works


 
 Why not join the two ...
 
   import x.y.mod alias t;
 
   t.foo();
 


Perfect.


 --Derek Parnell
 Melbourne, Australia
Jul 08 2006
prev sibling next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.tceexnbq6b8z09 ginger.vic.bigpond.net.au...

 On Sun, 09 Jul 2006 10:54:03 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:



 Alias also works fine for making substitutes for long, awkward names:

 import x.y.mod;
 alias x.y.mod t;

 x.y.mod.foo(); // works
 t.foo(); // also works


 Why not join the two ...

   import x.y.mod alias t;

   t.foo();


Good idea.  That way the aliases are right where you can see them as opposed 
to god knows where.


 -- 
 Derek Parnell
 Melbourne, Australia
Jul 08 2006
prev sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Derek Parnell wrote:


 Why not join the two ...
 
   import x.y.mod alias t;
 
   t.foo();


Not bad

-- 
AKhropov
Jul 09 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Kris wrote:

 Er, that really doesn't work at all. Please ignore what I said a few 
 minutes ago
 regarding this option (I really should get some sleep instead).
 The problem here is that, for the proposed static imports, everything 
 must be
 fully-qualified with the /original import name/, and that's just plain 
 awful for
 long import names. The "import as" allows one to give it a nice short 
 name
 instead.


 
 Alias also works fine for making substitutes for long, awkward names:
 
 import x.y.mod;
 alias x.y.mod t;
 
 x.y.mod.foo();    // works
 t.foo();    // also works


Yup.  'as' would just be a convenience and potentially add a slight bit 
of clarity.  Though I'll admit to sort of liking Kris' alternate 
interpretation where the alias prefix isn't optional.


 And, I still think the selective-import is the superior solution anyway.


 
 Semantically, it isn't any different. It would even be implemented 
 internally using the 'alias' machinery.


     module A;

     void foo() {}
     void bar() {}

     module B;

     void bar() {}

     module main;

     import A.foo;
     import B.bar;

     foo();
     bar(); // unambiguous

So not strictly the same, unless the proposal also involved always using 
a namespace qualifier?


Sean
Jul 08 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:
 

 Kris wrote:


 Er, that really doesn't work at all. Please ignore what I said a few 
 minutes ago
 regarding this option (I really should get some sleep instead).
 The problem here is that, for the proposed static imports, everything 
 must be
 fully-qualified with the /original import name/, and that's just 
 plain awful for
 long import names. The "import as" allows one to give it a nice short 
 name
 instead.



 Alias also works fine for making substitutes for long, awkward names:

 import x.y.mod;
 alias x.y.mod t;

 x.y.mod.foo();    // works
 t.foo();    // also works


 
 
 Yup.  'as' would just be a convenience and potentially add a slight bit 
 of clarity.  Though I'll admit to sort of liking Kris' alternate 
 interpretation where the alias prefix isn't optional.
 

 And, I still think the selective-import is the superior solution anyway.



 Semantically, it isn't any different. It would even be implemented 
 internally using the 'alias' machinery.


 
 
     module A;
 
     void foo() {}
     void bar() {}
 
     module B;
 
     void bar() {}
 
     module main;
 
     import A.foo;
     import B.bar;
 
     foo();
     bar(); // unambiguous
 
 So not strictly the same, unless the proposal also involved always using 
 a namespace qualifier?


I posted this proposal earlier, but I like it so much I'll repeat myself:

import B with bar;
bar(); // unambiguous

The point is you can list multiple names from the module without 
repeating the module name:

import MyModule with foo, baz;

And "with" is already a keyword.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 08 2006
next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Kirk McDonald wrote:

 import B with bar;
 bar(); // unambiguous
 
 The point is you can list multiple names from the module without 
 repeating the module name:
 
 import MyModule with foo, baz;
 
 And "with" is already a keyword.
 


To put this another way (forgive any errors in my syntax, I'm not used 
to it):

ImportDeclaration:
	import ModuleNameList ;

ModuleNameList:
	ModuleNameAliasWith
	ModuleNameAlias , ModuleNameList

ModuleNameAliasWith
	ModuleNameAlias
	ModuleNameAlias with IdentifierAliasList

ModuleNameAlias:
	ModuleName
	ModuleName alias Identifier

IdentifierAliasList:
	IdentifierAlias
	IdentifierAlias , IdentifierAliasList

IdentifierAlias:
	Identifier
	Identifier alias Identifier

Note that this means that as soon as "with" is used, you cannot specify 
any more modules in that import statement:

// Imports modules foo, bar, and baz, and aliases
// baz.a, baz.b, and baz.c
import foo, bar, baz with a, b, c;

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 08 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 11:59:37 +1000, Kirk McDonald  
<kirklin.mcdonald gmail.com> wrote:



 I posted this proposal earlier, but I like it so much I'll repeat myself:

 import B with bar;
 bar(); // unambiguous

 The point is you can list multiple names from the module without  
 repeating the module name:

 import MyModule with foo, baz;

 And "with" is already a keyword.


So what? But if you did want to reuse the "with" keyword why not use it in  
the same manner...

  with MyModule import foo, baz;


-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Derek Parnell wrote:

 On Sun, 09 Jul 2006 11:59:37 +1000, Kirk McDonald  
 <kirklin.mcdonald gmail.com> wrote:
 
 

 I posted this proposal earlier, but I like it so much I'll repeat myself:

 import B with bar;
 bar(); // unambiguous

 The point is you can list multiple names from the module without  
 repeating the module name:

 import MyModule with foo, baz;

 And "with" is already a keyword.


 
 
 So what? But if you did want to reuse the "with" keyword why not use it 
 in  the same manner...
 
  with MyModule import foo, baz;
 
 


It makes the grammar simpler to start both with "import," I think. I 
also think it reads better. Both work, though. I am not picky, and will 
be happy no matter what actual keywords we get for this functionality, 
so long as we get it.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 08 2006
parent kris <foo bar.com> writes:
Kirk McDonald wrote:

 Derek Parnell wrote:
 

 On Sun, 09 Jul 2006 11:59:37 +1000, Kirk McDonald  
 <kirklin.mcdonald gmail.com> wrote:



 I posted this proposal earlier, but I like it so much I'll repeat 
 myself:

 import B with bar;
 bar(); // unambiguous

 The point is you can list multiple names from the module without  
 repeating the module name:

 import MyModule with foo, baz;

 And "with" is already a keyword.




 So what? But if you did want to reuse the "with" keyword why not use 
 it in  the same manner...

  with MyModule import foo, baz;


 
 It makes the grammar simpler to start both with "import," I think. I 
 also think it reads better. Both work, though. I am not picky, and will 
 be happy no matter what actual keywords we get for this functionality, 
 so long as we get it.
 


That is *very* clear syntax. Hope you don't mind that I used it in a 
follow-up post ...
Jul 08 2006
prev sibling parent reply Tydr Schnubbis <fake address.dude> writes:
Derek Parnell wrote:

 The point is you can list multiple names from the module without  
 repeating the module name:

 import MyModule with foo, baz;

 And "with" is already a keyword.


 
 So what? But if you did want to reuse the "with" keyword why not use it in  
 the same manner...
 
   with MyModule import foo, baz;
 


This is starting to look a lot like Python syntax:

from MyModule import foo, baz
from MyModule import veryLongName as vln


If you use the simple syntax in Python, you need to fully qualify names 
when you use them:

import MyModule

MyModule.baz


You can also import all names into the current namespace:

from MyModule import *


Or alias:

import MyModule as MM


Would have been great to have all this control and flexibility in D.


Or instead of 'with', does using 'scope' make sense?

import scope MyModule foo, baz
Jul 09 2006
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Tydr Schnubbis wrote:

 Derek Parnell wrote:
 

 The point is you can list multiple names from the module without  
 repeating the module name:

 import MyModule with foo, baz;

 And "with" is already a keyword.



 So what? But if you did want to reuse the "with" keyword why not use 
 it in  the same manner...

   with MyModule import foo, baz;


 
 This is starting to look a lot like Python syntax:
 


[snip]

That's where it came from in the first place. :-)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 09 2006
prev sibling next sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <e8pk3b$26bo$1 digitaldaemon.com>, Walter Bright says...

Kris wrote:

 Er, that really doesn't work at all. Please ignore what I said a few minutes
ago
 regarding this option (I really should get some sleep instead). 
 
 The problem here is that, for the proposed static imports, everything must be
 fully-qualified with the /original import name/, and that's just plain awful
for
 long import names. The "import as" allows one to give it a nice short name
 instead.


Alias also works fine for making substitutes for long, awkward names:

import x.y.mod;
alias x.y.mod t;

x.y.mod.foo();	// works
t.foo();	// also works



 And, I still think the selective-import is the superior solution anyway.


Semantically, it isn't any different. It would even be implemented 
internally using the 'alias' machinery.



Walter,

The use of "alias" still looks like a hack.  We know you've always been firm in
your belief that "alias" is the way to do it.  I doubt that all these people
would be discussing options here if they were satisfied with that solution
(which has been around for a looong time).

We know it can be done with alias. Kris knows. We don't think it's good enough.
That's why this whole topic is being wrangled.  

So if you choose to make the internal machinery do it with alias, fine!  We just
want something that's better, nicer, more professional looking! :) (please not
"static import," though).

While I do agree that D would suffer if you followed the communities whim for
every little feature suggested, yet I think you are far too independent minded
most of the time.  The quote in your recent interview at Bitwise -- "D is going
wherever the D community wants it to go" -- is really a farce.  D is going where
/you/ want it to go, Walter. 

And there's nothing wrong with admitting that.  I just think a honesty is
important here.  This is your language.  You've made that very plain over the
years, and most of us who have stuck around have accepted that. You strongly
disfavour committees and bureaucracy, which is completely understandable; but,
your over-protectiveness and fear of them may be doing the same sort of damage
on the opposite end of the spectrum.

Don't take this wrong:  I'm very thankful about all you've done with D; I just
get a little frustrated at how hard you are to convince of anything, a trait
that may do well for you in some ways but probably hurts you so much more in
other ways.

-JJR
Jul 08 2006
next sibling parent kris <foo bar.com> writes:
John Reimer wrote:

 In article <e8pk3b$26bo$1 digitaldaemon.com>, Walter Bright says...
 

Kris wrote:


Er, that really doesn't work at all. Please ignore what I said a few minutes ago
regarding this option (I really should get some sleep instead). 

The problem here is that, for the proposed static imports, everything must be
fully-qualified with the /original import name/, and that's just plain awful for
long import names. The "import as" allows one to give it a nice short name
instead.


Alias also works fine for making substitutes for long, awkward names:

import x.y.mod;
alias x.y.mod t;

x.y.mod.foo();	// works
t.foo();	// also works




And, I still think the selective-import is the superior solution anyway.


Semantically, it isn't any different. It would even be implemented 
internally using the 'alias' machinery.


 
 
 
 Walter,
 
 The use of "alias" still looks like a hack.  We know you've always been firm in
 your belief that "alias" is the way to do it.  I doubt that all these people
 would be discussing options here if they were satisfied with that solution
 (which has been around for a looong time).
 
 We know it can be done with alias. Kris knows. We don't think it's good enough.
 That's why this whole topic is being wrangled.  
 
 So if you choose to make the internal machinery do it with alias, fine!  We
just
 want something that's better, nicer, more professional looking! :) (please not
 "static import," though).
 
 While I do agree that D would suffer if you followed the communities whim for
 every little feature suggested, yet I think you are far too independent minded
 most of the time.  The quote in your recent interview at Bitwise -- "D is going
 wherever the D community wants it to go" -- is really a farce.  D is going
where
 /you/ want it to go, Walter. 
 
 And there's nothing wrong with admitting that.  I just think a honesty is
 important here.  This is your language.  You've made that very plain over the
 years, and most of us who have stuck around have accepted that. You strongly
 disfavour committees and bureaucracy, which is completely understandable; but,
 your over-protectiveness and fear of them may be doing the same sort of damage
 on the opposite end of the spectrum.
 
 Don't take this wrong:  I'm very thankful about all you've done with D; I just
 get a little frustrated at how hard you are to convince of anything, a trait
 that may do well for you in some ways but probably hurts you so much more in
 other ways.
 
 -JJR
 
 
 



It takes a lot of courage to stand up and say something like that, so 
I'll be first to give you an ovation ... very well said, John. Hear Hear!

One has to wonder whether this type of online "environment" is conducive 
to solid progress anyway? I mean, we're all a bit disembodied, and the 
experience is really nothing like sitting down together for an afternoon 
with a whiteboard, and thrashing through issues. Can't even get close to 
that. We have zero body-language cues to guide us, and with differing 
opinions that can be a crucial factor in reaching a resolution or not.
Jul 08 2006
prev sibling next sibling parent Ant <duitoolkit yahoo.ca> writes:
John Reimer wrote:
[...]

thank you for saying that JJR.
I tried to say it before but my style is aggressive, curt and 
confrontational - but that's exactly what I meant.

and Walter dont' forget:

 Don't take this wrong:  I'm very thankful about all you've done with D; I just
 get a little frustrated at how hard you are to convince of anything


[...]

 -JJR


I give up posting because my posts became too negative.
but I'm still here - that says more then anything else.

thank again Walter.

Ant
Jul 08 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:

 The use of "alias" still looks like a hack.  We know you've always been firm in
 your belief that "alias" is the way to do it.  I doubt that all these people
 would be discussing options here if they were satisfied with that solution
 (which has been around for a looong time).
 
 We know it can be done with alias. Kris knows. We don't think it's good enough.
 That's why this whole topic is being wrangled.  
 
 So if you choose to make the internal machinery do it with alias, fine!  We
just
 want something that's better, nicer, more professional looking! :) (please not
 "static import," though).


What I don't get is what is "unprofessional" or hackish about alias? Is 
it (as I posted to Kris) that it looks too much like #define?



 While I do agree that D would suffer if you followed the communities whim for
 every little feature suggested, yet I think you are far too independent minded
 most of the time.  The quote in your recent interview at Bitwise -- "D is going
 wherever the D community wants it to go" -- is really a farce.  D is going
where
 /you/ want it to go, Walter.


If it was only what I wanted, there'd be exactly one D user - me. D 
really is a community effort, and it really does go where the community 
wants it to go (although it may not seem that way at times). Every day, 
and I mean every day, there are feature proposals. I have no choice but 
to say "no" to 99% of them, which sure comes off as me sounding like 
Negative Nellie or Dr. No.

This is despite the fact that many of them are incredibly good ideas, 
like Don's idea on temporaries.

Each idea goes through a gauntlet of:
1) is lack of this idea turning users away from D
2) how much power it adds
3) how much complexity it adds
4) is it consistent with the rest of D
5) how hard is it to implement
6) how does it rank in importance against all the other ideas

Here's one example: I'm not personally enamored with inner classes. 
There are better ways to do the same thing. But Kris made a compelling 
argument that supporting inner classes would open the door wide to mass 
conversion of Java code to D. That's a lot of leverage for a fairly 
modest implementation effort.



 And there's nothing wrong with admitting that.  I just think a honesty is
 important here.  This is your language.  You've made that very plain over the
 years, and most of us who have stuck around have accepted that. You strongly
 disfavour committees and bureaucracy, which is completely understandable; but,
 your over-protectiveness and fear of them may be doing the same sort of damage
 on the opposite end of the spectrum.


Sure, at the moment I make the final decisions. But that only is 
possible because the D community suffers me to do it. If I cease to act 
in the best interests of the D community, then the community can easily 
take D off in their own direction (D is GPL).


 Don't take this wrong:  I'm very thankful about all you've done with D; I just
 get a little frustrated at how hard you are to convince of anything, a trait
 that may do well for you in some ways but probably hurts you so much more in
 other ways.


Being hard to convince is the only practical way to find the 1% that 
must be done out of the 99% that I am forced to say no to.

P.S. If you think I'm hard to convince, try convincing the C++ standards 
committee of something <g>.

P.P.S. Don't think of it as just convincing me. You have to make an 
argument that is compelling to current and potential future users of D. 
The latter group is predisposed to be very skeptical about new 
languages. I've seen them in the audience of my talks, with arms crossed 
and head back. I have to present a pretty darned convincing case to get 
their attention.
Jul 09 2006
next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e8qf7k$2q0d$1 digitaldaemon.com...

 What I don't get is what is "unprofessional" or hackish about alias? Is it 
 (as I posted to Kris) that it looks too much like #define?


I think the problem with "alias" is that you'll have multiple ways to refer 
to the imported name.

You can use the FQN, the global one (in case there are no conflicts) and 
finally the aliased name. And there's no restriction: the code in that 
module could be using any of the three alternatives, or worse still, all! 
You'll have to keep track on a piece of paper (or comments :) that .foo == 
lib.bar.foo == myfoo.

An "import x as y" would leave only 1 alternative: y.
"static import" will still have two, the FQN and the alias.
(I liked "import x alias y", by the way)


 Each idea goes through a gauntlet of:
 1) is lack of this idea turning users away from D
 2) how much power it adds
 3) how much complexity it adds
 4) is it consistent with the rest of D
 5) how hard is it to implement
 6) how does it rank in importance against all the other ideas


Lets make this the official yardstick to which to subject all future 
proposals.

If you have an opinion on any feature request, no matter how silly the 
request, you should write a small reaction. Perhaps just a comment like 
"denied, see item 6 of The List". Of course, people will want to argue with 
you futher, but it's likely that the community can take it from there.

L.
Jul 10 2006
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:


 John Reimer wrote:

 The use of "alias" still looks like a hack.  We know you've always been
 firm in
 your belief that "alias" is the way to do it.  I doubt that all these
 people would be discussing options here if they were satisfied with that
 solution (which has been around for a looong time).
 
 We know it can be done with alias. Kris knows. We don't think it's good
 enough. That's why this whole topic is being wrangled.
 
 So if you choose to make the internal machinery do it with alias, fine! 
 We just want something that's better, nicer, more professional looking!
 :) (please not "static import," though).


 
 What I don't get is what is "unprofessional" or hackish about alias? Is
 it (as I posted to Kris) that it looks too much like #define?


I personally don't like it myself, first of all it is not a natural word for
me (I don't have English as my mother tongue, might very well be the
reason), but my understanding of the word make it very unlikely to me that
it actually _do_ something, it should just give something a different name.
Using it for anything else (pulling something from one namespace to
another, for instance when subclassing), or for making namespaces, is to me
the most unintuitive thing I've ever come across in a programming language
(I don't count COBOL here ...). I actually hate it :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 11 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Lars Ivar Igesund wrote:

 I personally don't like it myself, first of all it is not a natural word for
 me (I don't have English as my mother tongue, might very well be the
 reason), but my understanding of the word make it very unlikely to me that
 it actually _do_ something, it should just give something a different name.
 Using it for anything else (pulling something from one namespace to
 another, for instance when subclassing), or for making namespaces, is to me
 the most unintuitive thing I've ever come across in a programming language
 (I don't count COBOL here ...). I actually hate it :)


It does give something a different name, in the current namespace. You 
could think of it like what Python calls it: binding a name from another 
namespace into the local symbol table.

Or you could think of it like a 'reference' variable, such as inout 
function parameters.
Jul 11 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:


 Lars Ivar Igesund wrote:

 I personally don't like it myself, first of all it is not a natural word
 for me (I don't have English as my mother tongue, might very well be the
 reason), but my understanding of the word make it very unlikely to me
 that it actually _do_ something, it should just give something a
 different name. Using it for anything else (pulling something from one
 namespace to another, for instance when subclassing), or for making
 namespaces, is to me the most unintuitive thing I've ever come across in
 a programming language (I don't count COBOL here ...). I actually hate it
 :)


 
 It does give something a different name, in the current namespace. You
 could think of it like what Python calls it: binding a name from another
 namespace into the local symbol table.
 
 Or you could think of it like a 'reference' variable, such as inout
 function parameters.


Yes, I could, because those (especially bind) are much better words for what
actually happens.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 11 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
Lars Ivar Igesund wrote:

 Walter Bright wrote:
 

 John Reimer wrote:

 The use of "alias" still looks like a hack.  We know you've always been
 firm in
 your belief that "alias" is the way to do it.  I doubt that all these
 people would be discussing options here if they were satisfied with that
 solution (which has been around for a looong time).

 We know it can be done with alias. Kris knows. We don't think it's good
 enough. That's why this whole topic is being wrangled.

 So if you choose to make the internal machinery do it with alias, fine! 
 We just want something that's better, nicer, more professional looking!
 :) (please not "static import," though).


 What I don't get is what is "unprofessional" or hackish about alias? Is
 it (as I posted to Kris) that it looks too much like #define?


 
 I personally don't like it myself, first of all it is not a natural word for
 me (I don't have English as my mother tongue, might very well be the
 reason), but my understanding of the word make it very unlikely to me that
 it actually _do_ something, it should just give something a different name.
 Using it for anything else (pulling something from one namespace to
 another, for instance when subclassing), or for making namespaces, is to me
 the most unintuitive thing I've ever come across in a programming language
 (I don't count COBOL here ...). I actually hate it :)
 


Great point!! I *knew* there was something that just didn't feel right 
about explicitly using 'alias' for the purpose discussed here and that's it!
Jul 11 2006
prev sibling parent "Boris Wang" <nano.kago hotmail.com> writes:
Wow! Thanks!

what you said is i want to say long time ago.

but, my poor english....


In addition, sometime, we want doing something nicer, not only has ability 
to do. it's the different between professional and layman, maturity and 
babyhood.


"John Reimer" <John_member pathlink.com>
Đ´ČëĎűϢĐÂÎĹ:e8pptc$2acl$1 digitaldaemon.com...

 In article <e8pk3b$26bo$1 digitaldaemon.com>, Walter Bright says...

Kris wrote:

 Er, that really doesn't work at all. Please ignore what I said a few 
 minutes ago
 regarding this option (I really should get some sleep instead).

 The problem here is that, for the proposed static imports, everything 
 must be
 fully-qualified with the /original import name/, and that's just plain 
 awful for
 long import names. The "import as" allows one to give it a nice short 
 name
 instead.


Alias also works fine for making substitutes for long, awkward names:

import x.y.mod;
alias x.y.mod t;

x.y.mod.foo(); // works
t.foo(); // also works



 And, I still think the selective-import is the superior solution anyway.


Semantically, it isn't any different. It would even be implemented
internally using the 'alias' machinery.



 Walter,

 The use of "alias" still looks like a hack.  We know you've always been 
 firm in
 your belief that "alias" is the way to do it.  I doubt that all these 
 people
 would be discussing options here if they were satisfied with that solution
 (which has been around for a looong time).

 We know it can be done with alias. Kris knows. We don't think it's good 
 enough.
 That's why this whole topic is being wrangled.

 So if you choose to make the internal machinery do it with alias, fine! 
 We just
 want something that's better, nicer, more professional looking! :) (please 
 not
 "static import," though).

 While I do agree that D would suffer if you followed the communities whim 
 for
 every little feature suggested, yet I think you are far too independent 
 minded
 most of the time.  The quote in your recent interview at Bitwise -- "D is 
 going
 wherever the D community wants it to go" -- is really a farce.  D is going 
 where
 /you/ want it to go, Walter.

 And there's nothing wrong with admitting that.  I just think a honesty is
 important here.  This is your language.  You've made that very plain over 
 the
 years, and most of us who have stuck around have accepted that. You 
 strongly
 disfavour committees and bureaucracy, which is completely understandable; 
 but,
 your over-protectiveness and fear of them may be doing the same sort of 
 damage
 on the opposite end of the spectrum.

 Don't take this wrong:  I'm very thankful about all you've done with D; I 
 just
 get a little frustrated at how hard you are to convince of anything, a 
 trait
 that may do well for you in some ways but probably hurts you so much more 
 in
 other ways.

 -JJR
Jul 09 2006
prev sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 Kris wrote:
 

 Er, that really doesn't work at all. Please ignore what I said a few 
 minutes ago
 regarding this option (I really should get some sleep instead).
 The problem here is that, for the proposed static imports, everything 
 must be
 fully-qualified with the /original import name/, and that's just plain 
 awful for
 long import names. The "import as" allows one to give it a nice short 
 name
 instead.


 
 
 Alias also works fine for making substitutes for long, awkward names:
 
 import x.y.mod;
 alias x.y.mod t;
 
 x.y.mod.foo();    // works
 t.foo();    // also works
 
 

 And, I still think the selective-import is the superior solution anyway.


 
 
 Semantically, it isn't any different. It would even be implemented 
 internally using the 'alias' machinery.


Hrm;

The use of alias, regarding imports, should very likely be kept to a 
bare minimum in anything other than Q&D development. Ideally zero.

It's like the use of goto ~ use it where it can really help, but 
otherwise consider alternatives instead. I don't know what kind of 
development-scales you have in mind for D, but I'll happily testify that 
a boatload of aliases littering the imports would have no place in any 
project I'm responsible for; nor in those of the people I learned from. 
Here's why:

Quantities of alias do little but complicate ones comprehension of the 
code. Having a second-step (import then alias) is not only messy for 
each import, it does nothing to /encourage/ smart usage of namespace 
seperation. In fact, the extra step will likely discourage everyone but 
the diehards from using anything but the current global namespace, and 
we'll end up right back at square one.

At that point, the language would be lacking. And why? This is all about 
maturity and usability of the language in specific areas. Why the 
rollback to something that can be considered "arcane" instead?

Hey ~ if you'd actually roll in the changes, I'd be happy to make them 
myself ... I'd add both selective import and the "as" variation ~ a 
flexible combination to handle all cases, including the one Derek 
astutely pointed out. No aliases required by the user:

// import as we know it today, and with a required prefix "locale."
import lib.text.locale;
import lib.text.locale as locale;

// selective import of one entity, and alternatively with an alias
import lib.text.locale.Time;
import lib.text.locale.Time as otherTime;

==================================

Okay. Let's reflect for a moment?

The functionality is there, but the syntax could probably be better? 
There's a number of other posts proposing the use of "with" and so on, 
which look rather promising (from Kirk & Derek):

with lib.text.locale import Time, Date;

Seems pretty darned clear what's going on there. Seems to me that's a 
much more user-focused solution for selective imports. Let's combine 
this with a means to import an entire module under a prefix, as we've 
previously seen:

      // import as we know it today
import lib.text.locale;
auto time = new Time;

      // "locale." prefix required (great for IFTI modules)
import lib.text.locale as locale;
auto utc = locale.utcTime();
auto dst = locale.daylightSavings();

      // selective import
with lib.text.locale import Time, Date;
auto time = new Time;
auto date = new Date;

      // selective import with alias
with lib.text.locale import Time, Date as MyDate;
auto time = new Time;
auto date = new MyDate;

==================================

How about it?
Jul 08 2006
next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
kris wrote:

 Walter Bright wrote:
 

 Kris wrote:


 Er, that really doesn't work at all. Please ignore what I said a few 
 minutes ago
 regarding this option (I really should get some sleep instead).
 The problem here is that, for the proposed static imports, everything 
 must be
 fully-qualified with the /original import name/, and that's just 
 plain awful for
 long import names. The "import as" allows one to give it a nice short 
 name
 instead.




 Alias also works fine for making substitutes for long, awkward names:

 import x.y.mod;
 alias x.y.mod t;

 x.y.mod.foo();    // works
 t.foo();    // also works



 And, I still think the selective-import is the superior solution anyway.




 Semantically, it isn't any different. It would even be implemented 
 internally using the 'alias' machinery.


 
 
 Hrm;
 
 The use of alias, regarding imports, should very likely be kept to a 
 bare minimum in anything other than Q&D development. Ideally zero.
 
 It's like the use of goto ~ use it where it can really help, but 
 otherwise consider alternatives instead. I don't know what kind of 
 development-scales you have in mind for D, but I'll happily testify that 
 a boatload of aliases littering the imports would have no place in any 
 project I'm responsible for; nor in those of the people I learned from. 
 Here's why:
 
 Quantities of alias do little but complicate ones comprehension of the 
 code. Having a second-step (import then alias) is not only messy for 
 each import, it does nothing to /encourage/ smart usage of namespace 
 seperation. In fact, the extra step will likely discourage everyone but 
 the diehards from using anything but the current global namespace, and 
 we'll end up right back at square one.
 
 At that point, the language would be lacking. And why? This is all about 
 maturity and usability of the language in specific areas. Why the 
 rollback to something that can be considered "arcane" instead?
 
 Hey ~ if you'd actually roll in the changes, I'd be happy to make them 
 myself ... I'd add both selective import and the "as" variation ~ a 
 flexible combination to handle all cases, including the one Derek 
 astutely pointed out. No aliases required by the user:
 
 // import as we know it today, and with a required prefix "locale."
 import lib.text.locale;
 import lib.text.locale as locale;
 
 // selective import of one entity, and alternatively with an alias
 import lib.text.locale.Time;
 import lib.text.locale.Time as otherTime;
 
 ==================================
 
 Okay. Let's reflect for a moment?
 
 The functionality is there, but the syntax could probably be better? 
 There's a number of other posts proposing the use of "with" and so on, 
 which look rather promising (from Kirk & Derek):
 
 with lib.text.locale import Time, Date;
 
 Seems pretty darned clear what's going on there. Seems to me that's a 
 much more user-focused solution for selective imports. Let's combine 
 this with a means to import an entire module under a prefix, as we've 
 previously seen:
 
      // import as we know it today
 import lib.text.locale;
 auto time = new Time;
 
      // "locale." prefix required (great for IFTI modules)
 import lib.text.locale as locale;
 auto utc = locale.utcTime();
 auto dst = locale.daylightSavings();
 
      // selective import
 with lib.text.locale import Time, Date;
 auto time = new Time;
 auto date = new Date;
 
      // selective import with alias
 with lib.text.locale import Time, Date as MyDate;
 auto time = new Time;
 auto date = new MyDate;
 
 ==================================
 
 How about it?
 


Yes! All of this is good.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 08 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 The use of alias, regarding imports, should very likely be kept to a 
 bare minimum in anything other than Q&D development. Ideally zero.


I really don't understand your pov. I can't help but think you regard 
alias as like C++'s #define:

	alias foo bar;
	#define bar foo

Such #define's I would agree are a terrible hack that don't belong in 
professional code. But aliasing isn't like that, it's a sane and 
well-behaved replacement.


 It's like the use of goto ~ use it where it can really help, but 
 otherwise consider alternatives instead. I don't know what kind of 
 development-scales you have in mind for D, but I'll happily testify that 
 a boatload of aliases littering the imports would have no place in any 
 project I'm responsible for; nor in those of the people I learned from. 
 Here's why:
 
 Quantities of alias do little but complicate ones comprehension of the 
 code. Having a second-step (import then alias) is not only messy for 
 each import, it does nothing to /encourage/ smart usage of namespace 
 seperation. In fact, the extra step will likely discourage everyone but 
 the diehards from using anything but the current global namespace, and 
 we'll end up right back at square one.


With the "static import", there is no longer any possibility of name 
collisions, so we're not at square one. With no aliases, fully qualified 
module contents lookup will be needed.



 At that point, the language would be lacking. And why? This is all about 
 maturity and usability of the language in specific areas. Why the 
 rollback to something that can be considered "arcane" instead?


I don't see it as arcane or a workaround. Symbolic aliasing is a very 
powerful feature - yet it's very simple.



 Hey ~ if you'd actually roll in the changes, I'd be happy to make them 
 myself ... I'd add both selective import and the "as" variation ~ a 
 flexible combination to handle all cases, including the one Derek 
 astutely pointed out. No aliases required by the user:
 
 // import as we know it today, and with a required prefix "locale."
 import lib.text.locale;
 import lib.text.locale as locale;
 
 // selective import of one entity, and alternatively with an alias
 import lib.text.locale.Time;
 import lib.text.locale.Time as otherTime;
 
 ==================================


But those *are* aliases. It's just using a different keyword, "as" 
instead of "alias", and a slightly rearranged syntax. So what's the 
difference between:

import lib.text.locale.Time as otherTime;

and:

alias lib.text.locale.Time otherTime;

? Absolutely none, unless I am totally misunderstanding your proposal.



 Okay. Let's reflect for a moment?
 
 The functionality is there, but the syntax could probably be better? 
 There's a number of other posts proposing the use of "with" and so on, 
 which look rather promising (from Kirk & Derek):
 
 with lib.text.locale import Time, Date;
 
 Seems pretty darned clear what's going on there. Seems to me that's a 
 much more user-focused solution for selective imports. Let's combine 
 this with a means to import an entire module under a prefix, as we've 
 previously seen:
 
      // import as we know it today
 import lib.text.locale;
 auto time = new Time;
 
      // "locale." prefix required (great for IFTI modules)
 import lib.text.locale as locale;
 auto utc = locale.utcTime();
 auto dst = locale.daylightSavings();
 
      // selective import
 with lib.text.locale import Time, Date;
 auto time = new Time;
 auto date = new Date;
 
      // selective import with alias
 with lib.text.locale import Time, Date as MyDate;
 auto time = new Time;
 auto date = new MyDate;
 
 ==================================
 
 How about it?


       // "locale." prefix required (great for IFTI modules)
static import lib.text.locale;
alias lib.text.locale locale;
auto utc = locale.utcTime();
auto dst = locale.daylightSavings();

      // selective import
static import lib.text.locale;
alias lib.text.locale.Time Time;
alias lib.text.locale.Date Date;
auto time = new Time;
auto date = new Date;

      // selective import with alias
static import lib.text.locale;
alias lib.text.locale.Time Time;
alias lib.text.locale.Date MyDate;
auto time = new Time;
auto date = new MyDate;

These are semantically identical. The "static import" is a bit ugly 
looking, ok. It's a little wordier, ok. But it does work and produces 
exactly the results you asked for.

Let's harken back to the special regexp syntax I tried out a few months 
ago. It was a bit of syntactic sugar that reduced typing significantly. 
But it was soundly rejected by the community as adding complexity (in 
the form of more language to learn) while actually adding little to no 
extra power.

The "with" and "as" syntaxes add no power - they just save a little 
typing at the expense of adding more complexity to the grammar. Is that 
a worthwhile tradeoff? I don't know, but my inclination is to be 
conservative about such things.

I suggest trying out the "static import" for a while. See how it works 
and looks.
Jul 09 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 kris wrote:

 // import as we know it today, and with a required prefix "locale."
 import lib.text.locale;
 import lib.text.locale as locale;

 // selective import of one entity, and alternatively with an alias
 import lib.text.locale.Time;
 import lib.text.locale.Time as otherTime;

 ==================================


 
 But those *are* aliases. It's just using a different keyword, "as"
 instead of "alias", and a slightly rearranged syntax. So what's the
 difference between:
 
 import lib.text.locale.Time as otherTime;
 
 and:
 
 alias lib.text.locale.Time otherTime;
 
 ? Absolutely none, unless I am totally misunderstanding your proposal.


There should be a big difference (if I understand things correctly):
A simple example:

If I have:

module m1;

int func(){return 1;}

and

module mainmodule;

import m1;

void main()
{
  writefln(func());
  writefln(m1.func());
}

there are no problems with that!

But if I add:

module m2;

int func(){return 2;}

and change mainmodule to:

import m1;
import m2;

void main()
{
  writefln(func());     //<- conflict
  writefln(m1.func());
  writefln(m2.func());
}

And suddenly I get a lot of conflicts.

Sure there is a way to solve it by adding:

alias m1.func func;

And then use m2.func to use func from m2.

But what if I wanted to give m2.func a totally different name to avoid
confusion, i can try to add this:

alias m2.func someOtherName; instead of alias m1.func func;

But then once again I would get an error about a conflict:

Once again there is a solution:

alias m1.func func;
alias m2.func f2;

And it works OK, but the intention here is a bit hidden.

Conclusion:

import m2.func as f2;

is not the same as:

import m2;
alias m2.func f2;

but is equivalent to:

import m2;
alias m2.func f2;
//insert here a possibly huge number of aliases to avoid conflicts of
m2.func with func from other imported modules.
Jul 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Ivan Senji wrote:

 There should be a big difference (if I understand things correctly):
 A simple example:
 
 If I have:
 
 module m1;
 
 int func(){return 1;}
 
 and
 
 module mainmodule;
 
 import m1;
 
 void main()
 {
   writefln(func());
   writefln(m1.func());
 }
 
 there are no problems with that!
 
 But if I add:
 
 module m2;
 
 int func(){return 2;}
 
 and change mainmodule to:
 
 import m1;
 import m2;
 
 void main()
 {
   writefln(func());     //<- conflict
   writefln(m1.func());
   writefln(m2.func());
 }
 
 And suddenly I get a lot of conflicts.


I agree, but the "static import" resolves that.



 Sure there is a way to solve it by adding:
 
 alias m1.func func;
 
 And then use m2.func to use func from m2.
 
 But what if I wanted to give m2.func a totally different name to avoid
 confusion, i can try to add this:
 
 alias m2.func someOtherName; instead of alias m1.func func;
 
 But then once again I would get an error about a conflict:
 
 Once again there is a solution:
 
 alias m1.func func;
 alias m2.func f2;
 
 And it works OK, but the intention here is a bit hidden.
 
 Conclusion:
 
 import m2.func as f2;
 
 is not the same as:
 
 import m2;
 alias m2.func f2;
 
 but is equivalent to:
 
 import m2;
 alias m2.func f2;
 //insert here a possibly huge number of aliases to avoid conflicts of
 m2.func with func from other imported modules.


If "static import" is used, there aren't any conflicts.

There are two issues here:

1) the "second class name lookup" characteristic of import.
2) inserting a name from one scope into another (possibly renaming it in 
the process)

static import does (1) by importing but disabling the second class lookup.
alias does (2).
Jul 09 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Ivan Senji wrote:

 There should be a big difference (if I understand things correctly):
 A simple example:

 If I have:

 module m1;

 int func(){return 1;}

 and

 module mainmodule;

 import m1;

 void main()
 {
   writefln(func());
   writefln(m1.func());
 }

 there are no problems with that!

 But if I add:

 module m2;

 int func(){return 2;}

 and change mainmodule to:

 import m1;
 import m2;

 void main()
 {
   writefln(func());     //<- conflict
   writefln(m1.func());
   writefln(m2.func());
 }

 And suddenly I get a lot of conflicts.


 
 I agree, but the "static import" resolves that.


It does, but I thought your original example was solving the isue by
only importing one name from a module?


 
 

 Sure there is a way to solve it by adding:

 alias m1.func func;

 And then use m2.func to use func from m2.

 But what if I wanted to give m2.func a totally different name to avoid
 confusion, i can try to add this:

 alias m2.func someOtherName; instead of alias m1.func func;

 But then once again I would get an error about a conflict:

 Once again there is a solution:

 alias m1.func func;
 alias m2.func f2;

 And it works OK, but the intention here is a bit hidden.

 Conclusion:

 import m2.func as f2;

 is not the same as:

 import m2;
 alias m2.func f2;

 but is equivalent to:

 import m2;
 alias m2.func f2;
 //insert here a possibly huge number of aliases to avoid conflicts of
 m2.func with func from other imported modules.


 
 If "static import" is used, there aren't any conflicts.


OK.


 
 There are two issues here:
 
 1) the "second class name lookup" characteristic of import.
 2) inserting a name from one scope into another (possibly renaming it in
 the process)
 
 static import does (1) by importing but disabling the second class lookup.
 alias does (2).


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; ;) :)
Jul 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Jul 09 2006
next sibling parent reply kris <foo bar.com> writes:
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:
Jul 09 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
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.


 


Yes, but you could also:

import m2.func as f2, m2.abcd as f3, m2.efgh as f4;

It's not hard for us to understand, I think most of us just like the 
syntax better and it encourages that these aliases will be kept at the 
'top' of a module for easier maintenance!


 
 You've seen the requested syntax for this option, Walter. Let's revisit 
 it again:
 

 
 


That doesn't address the aliasing if I'm understanding correctly (what 
if m3 is imported and has an 'abcd' and 'efgh' also)?

Also, I don't like the 'with' because it breaks the continuity of a page 
scan (for me at least). May seem silly, but I'm expecting to see lines 
starting with 'import' or 'private import' when I check out what people 
are importing.
Jul 09 2006
next sibling parent reply kris <foo bar.com> writes:
Dave wrote:

 kris wrote:

 You've seen the requested syntax for this option, Walter. Let's 
 revisit it again:




 
 That doesn't address the aliasing if I'm understanding correctly (what 
 if m3 is imported and has an 'abcd' and 'efgh' also)?



The proposed syntax for that has been noted as the following:



or



This align well with the non-selective import:





 Also, I don't like the 'with' because it breaks the continuity of a page 
 scan (for me at least). May seem silly, but I'm expecting to see lines 
 starting with 'import' or 'private import' when I check out what people 
 are importing.



Yes, I agree. But feel the from/with syntax is quite suitable compared 
to the having a slew of alias decls polluting the import space.
Jul 09 2006
parent Dave <Dave_member pathlink.com> writes:
kris wrote:

 Dave wrote:

 kris wrote:

 You've seen the requested syntax for this option, Walter. Let's 
 revisit it again:




 That doesn't address the aliasing if I'm understanding correctly (what 
 if m3 is imported and has an 'abcd' and 'efgh' also)?


 
 
 The proposed syntax for that has been noted as the following:
 

 
 or
 



Thanks for the clarification - I had missed where the aliasing could 
also be done with 'from'.
Jul 09 2006
prev sibling parent kris <foo bar.com> writes:
Dave wrote:

 That doesn't address the aliasing if I'm understanding correctly (what 
 if m3 is imported and has an 'abcd' and 'efgh' also)?


Dave; the other option proposed earlier (by Walter) was to extend the 
import syntax to hit top-level decls within a module:



Which can be extended in the following manner:



The potential drawback to this is that you basically get one import at a 
time. But that's fine if continuity is more important.

Each of these options are listed in the root of this thread-branch: 
"Import concerns revisited"
Jul 09 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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:
 



The equivalent would be:

	with m2 import func as f2, abcd as f3, efgh as f4;
Jul 11 2006
parent reply Dave <Dave_member pathlink.com> writes:
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:




 
 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).
Jul 11 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e90enb$2cbl$1 digitaldaemon.com>, Dave says...

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:




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


I think something like these are even better (though in the end it's going to be
an opinion thing):

import m2 = f2, abcd = f3, efgh = f4;
import m2 : f2, abcd : f3, efgh : f4;

I don't know why "as" would be used as an identifier, but D already has enough
keywords! ;)

jcc7
Jul 11 2006
parent Dave <Dave_member pathlink.com> writes:
jcc7 wrote:

 In article <e90enb$2cbl$1 digitaldaemon.com>, Dave says...

 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:




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

 I think something like these are even better (though in the end it's 


going to be

 an opinion thing):

 import m2 = f2, abcd = f3, efgh = f4;
 import m2 : f2, abcd : f3, efgh : f4;

 I don't know why "as" would be used as an identifier, but D already 


has enough

 keywords! ;)


With one clarification:

import theAlias = theSymbol; // right associative
import theSymbol : theAlias;

or even simpler (and matching alias syntax)

import theSymbol theAlias;

Either one fine by me!


 jcc7
Jul 11 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 19:52:15 +1000, Walter Bright  
<newshound digitalmars.com> 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.


One very important purpose of programming languages is to help make sense  
to human readers and writers. Redundant repetition is distracting in  
everything except poetry.

Consider this instead ...

  from m2 import f2,f3,f4;

or

  with m2 import f2,f3,f4;

Much easier to write, reead and understand. And probably easier for the  
compiler too.

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

-- 
Derek Parnell
Melbourne, Australia
Jul 09 2006
next sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Derek Parnell wrote:


 *Please* do not overload the "static" keyword with yet another definition.


I generally agree.
 But I think it wouldn't be a big problem if we get used to it. 
Anyway an alternative is to introduce some new keyword, isn't it?

-- 
AKhropov
Jul 09 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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.)
Jul 11 2006
prev sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <e8qjkf$2tqc$1 digitaldaemon.com>, Walter Bright says...

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.


Well, your example is just showing selective renaming from /one/ module.
Naturally these two are going to be very similar.  Please look at Kris'
suggestion, thoroughly.  The whole system is vastly superior once one starts
referencing selective importing from multiple modules.  The total number of
lines are cut in half verses using static import and alias.

Also, for selective import, I think using "from" instead of "with" looks much
better.

-JJR
Jul 09 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
John Reimer wrote:

 In article <e8qjkf$2tqc$1 digitaldaemon.com>, Walter Bright says...

 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.


 
 Well, your example is just showing selective renaming from /one/ module.
 Naturally these two are going to be very similar.  Please look at Kris'
 suggestion, thoroughly.  The whole system is vastly superior once one starts
 referencing selective importing from multiple modules.  The total number of
 lines are cut in half verses using static import and alias.
 
 Also, for selective import, I think using "from" instead of "with" looks much
 better.


I agree that 'from' is better than 'with', but I just don't see the 
advantage of

from m2 import func,abcd,efgh;

over the likes of

import m2.func, m2.abcd, m2.efgh as f4;
import std.stdio, this.other.cool.db.lib as dblib;

because then you get the aliasing in there as well. True, there's a 
little redundant typing of 'm2'.

Also,

from m2 private import func,abcd,efgh;

or

private from m2 import func,abcd,efgh;

sucks IMO.


 
 -JJR
Jul 09 2006
parent reply Sean Kelly <sean f4.ca> writes:
Dave wrote:

 John Reimer wrote:

 In article <e8qjkf$2tqc$1 digitaldaemon.com>, Walter Bright says...

 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.


 Well, your example is just showing selective renaming from /one/ module.
 Naturally these two are going to be very similar.  Please look at Kris'
 suggestion, thoroughly.  The whole system is vastly superior once one 
 starts
 referencing selective importing from multiple modules.  The total 
 number of
 lines are cut in half verses using static import and alias.

 Also, for selective import, I think using "from" instead of "with" 
 looks much
 better.


 
 I agree that 'from' is better than 'with', but I just don't see the 
 advantage of
 
 from m2 import func,abcd,efgh;
 
 over the likes of
 
 import m2.func, m2.abcd, m2.efgh as f4;
 import std.stdio, this.other.cool.db.lib as dblib;
 
 because then you get the aliasing in there as well. True, there's a 
 little redundant typing of 'm2'.


If 'm2' is actually 'some.guys.super.cool.library.module' then the 
redundant typing adds up.


 Also,
 
 from m2 private import func,abcd,efgh;
 
 or
 
 private from m2 import func,abcd,efgh;
 
 sucks IMO.


I don't really mind the former, and I wouldn't terribly mind the latter 
if expressed differently:

private
{
     from m2 import func, abcd, efgh;
}

Though I think the real utility with the from/with syntax is that it 
would allow for selective public exposure of symbols to importing modules.


Sean
Jul 09 2006
parent reply Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:

 Dave wrote:

 John Reimer wrote:

 In article <e8qjkf$2tqc$1 digitaldaemon.com>, Walter Bright says...

 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.


 Well, your example is just showing selective renaming from /one/ module.
 Naturally these two are going to be very similar.  Please look at Kris'
 suggestion, thoroughly.  The whole system is vastly superior once one 
 starts
 referencing selective importing from multiple modules.  The total 
 number of
 lines are cut in half verses using static import and alias.

 Also, for selective import, I think using "from" instead of "with" 
 looks much
 better.


 I agree that 'from' is better than 'with', but I just don't see the 
 advantage of

 from m2 import func,abcd,efgh;

 over the likes of

 import m2.func, m2.abcd, m2.efgh as f4;
 import std.stdio, this.other.cool.db.lib as dblib;

 because then you get the aliasing in there as well. True, there's a 
 little redundant typing of 'm2'.


 
 If 'm2' is actually 'some.guys.super.cool.library.module' then the 
 redundant typing adds up.


But then you could alias some.guys.super.cool.library.module, er,  no 
wait... <g>

Seriously, you're spot on - I didn't consider that.


 

 Also,

 from m2 private import func,abcd,efgh;

 or

 private from m2 import func,abcd,efgh;

 sucks IMO.


 
 I don't really mind the former, and I wouldn't terribly mind the latter 
 if expressed differently:
 
 private
 {
     from m2 import func, abcd, efgh;
 }
 
 Though I think the real utility with the from/with syntax is that it 
 would allow for selective public exposure of symbols to importing modules.
 
 
 Sean
Jul 09 2006
parent reply Dave <Dave_member pathlink.com> writes:
Dave wrote:

 Sean Kelly wrote:

 Dave wrote:

 I agree that 'from' is better than 'with', but I just don't see the 
 advantage of

 from m2 import func,abcd,efgh;

 over the likes of

 import m2.func, m2.abcd, m2.efgh as f4;
 import std.stdio, this.other.cool.db.lib as dblib;

 because then you get the aliasing in there as well. True, there's a 
 little redundant typing of 'm2'.


 If 'm2' is actually 'some.guys.super.cool.library.module' then the 
 redundant typing adds up.


 
 But then you could alias some.guys.super.cool.library.module, er,  no 
 wait... <g>
 
 Seriously, you're spot on - I didn't consider that.
 


Actually, how about:

import from some.long.modid func as f1, abcd, efgh as zzz;
private import from this.other.cool.db.lib as dblib;

Is more consistent w/ current syntax, maintains the visual continuity, 
allows more than one symbol import per module (w/o retyping the module), 
and combines the import w/ the alias if desired.

- Dave
Jul 09 2006
parent reply kris <foo bar.com> writes:
Dave wrote:

 Actually, how about:
 
 import from some.long.modid func as f1, abcd, efgh as zzz;
 private import from this.other.cool.db.lib as dblib;
 
 Is more consistent w/ current syntax, maintains the visual continuity, 
 allows more than one symbol import per module (w/o retyping the module), 
 and combines the import w/ the alias if desired.
 
 - Dave



Don't wish to belabour the point, but why the private attribute when 
it's not really required?

Traditional import:

a - import lib.text.locale;

Safe import:

b - import lib.text.locale as locale;


Selective safe import variations:

1 - import from lib.text.locale Date, Time as myTime;

2 - import lib.text.locale.Date;
     import lib.text.locale.Time as myTime;

3 - with lib.text.locale import Date, Time as myTime;



like the most appropriate in that context? Although the latter seems 

of the leading "import"

Whatever the outcome, daily usage should be simple to use and maintain, 
obvious, and not tiresomely redundant -- we want to encourage the use of 
the safe import.

------------

Contrived illustration:

module lib.net.server.ftp;

import lib.io.file,
        lib.text.convert.utf as utf;

import from lib.text.locale Date, Time;
Jul 09 2006
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Sun, 09 Jul 2006 16:57:55 -0700, kris wrote:


 Dave wrote:

 Actually, how about:
 
 import from some.long.modid func as f1, abcd, efgh as zzz;
 private import from this.other.cool.db.lib as dblib;
 
 Is more consistent w/ current syntax, maintains the visual continuity, 
 allows more than one symbol import per module (w/o retyping the module), 
 and combines the import w/ the alias if desired.
 
 - Dave


 
 Don't wish to belabour the point, but why the private attribute when 
 it's not really required?


Because a 'private' import is supposed to prevent modules that import the
one with the private import from seeing the members of that privately
imported module. Otherwise it could reference those members *as if* it had
also imported it.

The examples below ignore the current bug in DMD about FQN overriding
privacy.

 -- aaa.d --
 int X;

 -- bbb.d --
 private import aaa;
 void func_bbb()
 {
  aaa.X = 1;
 }

 -- ccc.d ---
 import bbb;
 void func_ccc()
 {
  aaa.X = 5; // Illegal 'cos bbb imported aaa privately.
 }


However ...

 -- bbb.d --
 import aaa;
 void func_bbb()
 {
  aaa.X = 1;
 }

 -- ccc.d ---
 import bbb;
 void func_ccc()
 {
  aaa.X = 5; // Okay now.
 }


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
10/07/2006 10:45:15 AM
Jul 09 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
kris wrote:

 Dave wrote:

 Actually, how about:

 import from some.long.modid func as f1, abcd, efgh as zzz;
 private import from this.other.cool.db.lib as dblib;

 Is more consistent w/ current syntax, maintains the visual continuity, 
 allows more than one symbol import per module (w/o retyping the 
 module), and combines the import w/ the alias if desired.

 - Dave


 
 
 Don't wish to belabour the point, but why the private attribute when 
 it's not really required?
 


I missed that... You're right, no need for 'private'.


 Traditional import:
 
 a - import lib.text.locale;
 
 Safe import:
 
 b - import lib.text.locale as locale;
 
 
 Selective safe import variations:
 
 1 - import from lib.text.locale Date, Time as myTime;
 
 2 - import lib.text.locale.Date;
     import lib.text.locale.Time as myTime;
 
 3 - with lib.text.locale import Date, Time as myTime;
 
 

 like the most appropriate in that context? Although the latter seems 

 of the leading "import"
 


I tend to forget things if I don't use a syntax (or a language) for a 
while; the more consistent things are the less I have to RTFM for 
something I've forgotten - just my preference. I think it'll probably be 
important for brand-newbies too, along with the aforementioned scanning 
code for imports.

The other part of it is that the C-lineage languages all start their 




 Whatever the outcome, daily usage should be simple to use and maintain, 
 obvious, and not tiresomely redundant -- we want to encourage the use of 
 the safe import.
 
 ------------
 
 Contrived illustration:
 
 module lib.net.server.ftp;
 
 import lib.io.file,
        lib.text.convert.utf as utf;
 
 import from lib.text.locale Date, Time;
Jul 09 2006
parent reply Dave <Dave_member pathlink.com> writes:
Dave wrote:

 kris wrote:

 Dave wrote:

 Actually, how about:

 import from some.long.modid func as f1, abcd, efgh as zzz;
 private import from this.other.cool.db.lib as dblib;

 Is more consistent w/ current syntax, maintains the visual 
 continuity, allows more than one symbol import per module (w/o 
 retyping the module), and combines the import w/ the alias if desired.

 - Dave



 Don't wish to belabour the point, but why the private attribute when 
 it's not really required?


 
 I missed that... You're right, no need for 'private'.
 


Hmm, that is if the new syntax proposals import exclusively into the 
current module, which I had thought I'd read somewhere earlier when I 
replied. Is that the case?

Otherwise 'private import' would be needed for the same reasons it is 
used now.


 Traditional import:

 a - import lib.text.locale;

 Safe import:

 b - import lib.text.locale as locale;


 Selective safe import variations:

 1 - import from lib.text.locale Date, Time as myTime;

 2 - import lib.text.locale.Date;
     import lib.text.locale.Time as myTime;

 3 - with lib.text.locale import Date, Time as myTime;



 like the most appropriate in that context? Although the latter seems 

 consistency of the leading "import"


 
 I tend to forget things if I don't use a syntax (or a language) for a 
 while; the more consistent things are the less I have to RTFM for 
 something I've forgotten - just my preference. I think it'll probably be 
 important for brand-newbies too, along with the aforementioned scanning 
 code for imports.
 
 The other part of it is that the C-lineage languages all start their 


 

 Whatever the outcome, daily usage should be simple to use and 
 maintain, obvious, and not tiresomely redundant -- we want to 
 encourage the use of the safe import.

 ------------

 Contrived illustration:

 module lib.net.server.ftp;

 import lib.io.file,
        lib.text.convert.utf as utf;

 import from lib.text.locale Date, Time;
Jul 09 2006
parent kris <foo bar.com> writes:
Dave wrote:

 Dave wrote:

 kris wrote:

 Don't wish to belabour the point, but why the private attribute when 
 it's not really required?


 I missed that... You're right, no need for 'private'.


 
 Hmm, that is if the new syntax proposals import exclusively into the 
 current module, which I had thought I'd read somewhere earlier when I 
 replied. Is that the case?
 
 Otherwise 'private import' would be needed for the same reasons it is 
 used now.


I apologize ... thought you were using the 'private' keyword as a 
replacement for Walter's "static import" thingy ... Sorry

So, yes ~ private/package/public/whatever should operate exactly as it 
does today. Well, I mean "operate as it is supposed to work" today ;)
Jul 09 2006
prev sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
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.

For the same reason I suggested "in" instead of "as", even though the meaning
may not be quite as obvious.
Jul 09 2006
next sibling parent reply John Reimer <John_member pathlink.com> writes:
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.



For the same reason I suggested "in" instead of "as", even though the meaning
may not be quite as obvious.



"in" seems inappropriate in this situation.  "as" perfectly correlates to a
renaming or aliasing action.  "in" is confusing and looks more like an action on
a set.

-JJR
Jul 09 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jul 09 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 10 Jul 2006 08:43:17 +1000, Regan Heath <regan netwin.co.nz> wrote:


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


I don't use multi-character identifier names that don't have at least one  
uppercase character. ;)


-- 
Derek Parnell
Melbourne, Australia
Jul 09 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 10 Jul 2006 09:30:32 +1000, Derek Parnell <derek psych.ward> wrote:

 On Mon, 10 Jul 2006 08:43:17 +1000, Regan Heath <regan netwin.co.nz>  
 wrote:


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


 I don't use multi-character identifier names that don't have at least  
 one uppercase character. ;)


Ahh.. you'd call it "emailFrom" or "EmailFrom" or similar. :)

Regan
Jul 09 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 10 Jul 2006 11:32:45 +1200, Regan Heath wrote:


 You don't write a mail server ;)


 I don't use multi-character identifier names that don't have at least  
 one uppercase character. ;)


 
 Ahh.. you'd call it "emailFrom" or "EmailFrom" or similar. :)


Yeah, something like that.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
10/07/2006 10:43:46 AM
Jul 09 2006
prev sibling parent reply John Reimer <John_member pathlink.com> writes:
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

-JJR
Jul 09 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
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.
Jul 11 2006
prev sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
John Reimer wrote:

 "in" seems inappropriate in this situation.  "as" perfectly correlates to a
 renaming or aliasing action.  "in" is confusing and looks more like an action
on
 a set.
 


If you read it as "into" I think it should make sense, if you think of
namespaces:

import foo.bar in foobar; // import foo.bar into the foobar namespace
Jul 09 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Deewiant wrote:

 John Reimer wrote:
 

"in" seems inappropriate in this situation.  "as" perfectly correlates to a
renaming or aliasing action.  "in" is confusing and looks more like an action on
a set.


 
 
 If you read it as "into" I think it should make sense, if you think of
namespaces:
 
 import foo.bar in foobar; // import foo.bar into the foobar namespace


Except you aren't importing it /into/ the foobar namespace, you're 
importing it /as/ the foobar namespace.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 09 2006
parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Kirk McDonald wrote:

 Deewiant wrote:

 John Reimer wrote:


 "in" seems inappropriate in this situation.  "as" perfectly
 correlates to a
 renaming or aliasing action.  "in" is confusing and looks more like
 an action on
 a set.



 If you read it as "into" I think it should make sense, if you think of
 namespaces:

 import foo.bar in foobar; // import foo.bar into the foobar namespace


 
 Except you aren't importing it /into/ the foobar namespace, you're
 importing it /as/ the foobar namespace.
 


What's the difference? I create the namespace when importing a module, and put
everything from that module /into/ the namespace.

If it won't be possible to import multiple modules into the same namespace, then
"as" might make more sense, I admit. But IMHO the difference between the
meanings is so small that we don't need a new keyword for this; overloading
"static" yet again, on the other hand, is much worse, and the new meaning is far
from intuitive.
Jul 10 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Deewiant wrote:

 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.


Yup, thus the suggestion of using "with" instead: it's already a keyword 
with similar meaning, and it should be fairly easy to disambiguate at 
the parse stage by looking ahead for "import".


Sean
Jul 09 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Ivan Senji wrote:

 There should be a big difference (if I understand things correctly):
 A simple example:

 If I have:

 module m1;

 int func(){return 1;}

 and

 module mainmodule;

 import m1;

 void main()
 {
   writefln(func());
   writefln(m1.func());
 }

 there are no problems with that!

 But if I add:

 module m2;

 int func(){return 2;}

 and change mainmodule to:

 import m1;
 import m2;

 void main()
 {
   writefln(func());     //<- conflict
   writefln(m1.func());
   writefln(m2.func());
 }

 And suddenly I get a lot of conflicts.


 
 I agree, but the "static import" resolves that.
 
 

 Sure there is a way to solve it by adding:

 alias m1.func func;

 And then use m2.func to use func from m2.

 But what if I wanted to give m2.func a totally different name to avoid
 confusion, i can try to add this:

 alias m2.func someOtherName; instead of alias m1.func func;

 But then once again I would get an error about a conflict:

 Once again there is a solution:

 alias m1.func func;
 alias m2.func f2;

 And it works OK, but the intention here is a bit hidden.

 Conclusion:

 import m2.func as f2;

 is not the same as:

 import m2;
 alias m2.func f2;

 but is equivalent to:

 import m2;
 alias m2.func f2;
 //insert here a possibly huge number of aliases to avoid conflicts of
 m2.func with func from other imported modules.


 
 If "static import" is used, there aren't any conflicts.
 
 There are two issues here:
 
 1) the "second class name lookup" characteristic of import.
 2) inserting a name from one scope into another (possibly renaming it in 
 the process)
 
 static import does (1) by importing but disabling the second class lookup.
 alias does (2).


Walter, I think what most are getting at here is that the 'as' syntax 
just seems cleaner and more efficient from a coding and maintenance POV.

If it's easy to implement, then I say go for it. If nothing else, people 
can still use 'explicit' aliasing. I argue that 'as' will actually be 
quicker for newbies to grasp (*especially* when they see it in example 
code), and my sense is that it will be a boon to maintenance because it 
generally won't end-up buried in the middle of a module like many 
aliases would be. It's not like alias will be a wasted feature - most 
prominently it will be used for storage types; it just feels more 
'natural' that way.
Jul 09 2006
next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
Please, no new keywords!

We can't solve this namespace polution by adding another keyword... 
Especially a short one.

My vote goes to:  import some.mod alias mymod;

No new keyword; existing keyword used with similar function, but different 
context, so should parse just fine.

My 2c.

L.
Jul 10 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Dave wrote:

 Walter, I think what most are getting at here is that the 'as' syntax 
 just seems cleaner and more efficient from a coding and maintenance POV.
 
 If it's easy to implement, then I say go for it. If nothing else, people 
 can still use 'explicit' aliasing. I argue that 'as' will actually be 
 quicker for newbies to grasp (*especially* when they see it in example 
 code), and my sense is that it will be a boon to maintenance because it 
 generally won't end-up buried in the middle of a module like many 
 aliases would be. It's not like alias will be a wasted feature - most 
 prominently it will be used for storage types; it just feels more 
 'natural' that way.


I think you're saying that this is not a discussion about functionality, 
but about aesthetics. I agree with that.

A couple of people have brought up the alias-in-the-middle thing:

1) If it's in the middle because it's in a nested scope, then it only 
applies for the duration of that scope. Presumably, it would be easily 
visible to anyone looking at that scope.

2) I think we can all agree that if it is at module scope in the middle, 
that is probably bad coding style - especially if there are forward 
references to it.

3) The with-import-as won't eliminate bad coding style with aliases. One 
can still plop an alias down in the middle of the module.

4) At least with aliases, they need to be defined within the module. 
This means one can do a simple search of one source file to find any 
aliases.

Let's look a bit at the aesthetics:

	with foo.bar import
		abc as def,
		ghi as jkl,
		mno;

	import very.long.name as N;
vs:
	static import foo.bar;
		alias foo.bar.abc def;
		alias foo.bar.ghi jkl;
		alias foo.bar.mno mno;

	import very.long.name;
		alias very.long.name N;


Yes, the latter is more typing. If one was to do this a lot, it can get 
annoying. But is it going to be done a lot? I think that is the crux of 
the matter.

P.S. There are other possible syntaxes:

	import foo.bar
	{	def = abc,
		jkl = ghi,
		mno,
	}
Jul 11 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Dave wrote:

 Walter, I think what most are getting at here is that the 'as' syntax 
 just seems cleaner and more efficient from a coding and maintenance POV.

 If it's easy to implement, then I say go for it. If nothing else, 
 people can still use 'explicit' aliasing. I argue that 'as' will 
 actually be quicker for newbies to grasp (*especially* when they see 
 it in example code), and my sense is that it will be a boon to 
 maintenance because it generally won't end-up buried in the middle of 
 a module like many aliases would be. It's not like alias will be a 
 wasted feature - most prominently it will be used for storage types; 
 it just feels more 'natural' that way.




(I'm pretty tired so forgive me for being succinct/unclear)


 I think you're saying that this is not a discussion about functionality, 
 but about aesthetics. I agree with that.
 
 A couple of people have brought up the alias-in-the-middle thing:
 
 1) If it's in the middle because it's in a nested scope, then it only 
 applies for the duration of that scope. Presumably, it would be easily 
 visible to anyone looking at that scope.

 2) I think we can all agree that if it is at module scope in the middle, 
 that is probably bad coding style - especially if there are forward 
 references to it.


Certainly.  However, it's been my experience that the vast majority of 
programmers on any given project tend not to be particularly scrupulous 
with their coding style, and code quality tends to degenerate over time. 
  Therefore, I believe that any means available to encourage good coding 
style and ease readability is worth considering quite carefully.  Having 
literally tossed old projects in the trash because the cost of 
maintenance was actually higher than a complete rewrite, I really can't 
stress this point enough.  But please note that I'm not suggesting a 
language or tool should in any way "dumb itself down" for the user, only 
that aesthetics plays a significant role in determining whether a 
particular feature or technique will be successful.


 3) The with-import-as won't eliminate bad coding style with aliases. One 
 can still plop an alias down in the middle of the module.


I do believe that bad code typically results from a few common causes:

* The programmer honestly doesn't know any better.  Often he's a novice 
or simply hasn't been exposed to the level of programming required for 
the task assigned.

* The programmer knows better but is in a hurry and doesn't care about 
cutting a few corners.  He'll go back and fix it when there's more time. 
  And that time will never be available.

In both of these cases, language aesthetics makes a difference.  In the 
first case, a mentor could suggest an alternate approach.  For this to 
succeed the learning programmer must be able to remember the solution 
and it must be fairly easy to execute.  If not, the programmer is 
destined to become a member of the second category, as he now knows 
better but finds some excuse not to use the technique anyway, often 
because he can't remember the details or because it requires too much 
typing.  In both cases, having support for the suggested technique built 
into the language or tool is ideal, as it presents both a syntactical 
reminder and a simpler way to accomplish the task than the programmer 
would be inclined to use otherwise.  Finally, if the technique *looks 
better* than another method and it's used pervasively, it will typically 
be followed by others (the broken window problem).


 4) At least with aliases, they need to be defined within the module. 
 This means one can do a simple search of one source file to find any 
 aliases.


Given the size of some of the source files I've seen, even a directed 
keyword search may take some time.  This simply doesn't compare to a 
glance at the import line.


 Let's look a bit at the aesthetics:
 
     with foo.bar import
         abc as def,
         ghi as jkl,
         mno;
 
     import very.long.name as N;
 vs:
     static import foo.bar;
         alias foo.bar.abc def;
         alias foo.bar.ghi jkl;
         alias foo.bar.mno mno;
 
     import very.long.name;
         alias very.long.name N;
 
 
 Yes, the latter is more typing. If one was to do this a lot, it can get 
 annoying. But is it going to be done a lot? I think that is the crux of 
 the matter.


Assuming the language stays as-is, I believe the aliasing will likely be 
limited to instances where collisions occur, as the technique is easy to 
forget and requires a lot of typing.  I expect this will also lead to 
maintenance issues as library upgrades cause symbol collisions and such.

As for qualifiers themselves, I expect the typical module name to be at 
least two levels deep:

     import product.package.module;

and often more for large libraries.  Mango is a useful reference here, 
and serves to support this assertion.


 P.S. There are other possible syntaxes:
 
     import foo.bar
     {    def = abc,
         jkl = ghi,
         mno,
     }


As long as the syntax is aesthetically pleasing and 
logically/structurally similar to Kris' proposal, I won't bicker over 
minutiae.  That isn't too say I'm overly fond of the syntax you just 
suggested, but I do understand that a slightly different syntax may 
parse more easily or  better fit the 'feel' of the language as a whole.


Sean
Jul 11 2006
next sibling parent reply xs0 <xs0 xs0.com> writes:
 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?

OT: if you'll be changing the import system, _PLEASE_ make private 
imports the default.


xs0
Jul 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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. 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.
Jul 11 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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. 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, who did ever say that was a good idea, everything public by
default? ;) And nothing is ever too late :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


I did <g>.
Jul 12 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:


 Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


 
 I did <g>.


Right :) I don't agree.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 12 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Lars Ivar Igesund wrote:

 Walter Bright wrote:
 

 Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


 I did <g>.


 
 Right :) I don't agree.


Let me explain why I think default public is a good idea.

It reduces clutter in sample, example, and quick programs. Access 
security is an advanced feature, one that's invaluable for a complex 
project, but is just in the way for smaller ones.

I don't mind at all when crafting a carefully designed, reusable module 
that 'private' needs to be explicit. It helps document the intention, 
and lends the impression that the designer did put some thought into the 
code.

But when writing illustrative sample code, I feel that having to add in 
'public's is distracting from the point (unless, of course, the point is 
about how access control works!). I see this a lot in sample C++ code, 
and it is distracting, to me anyway.

And it's just plain irritating when writing smaller programs where 
access control is quite irrelevant.
Jul 12 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:


 Lars Ivar Igesund wrote:

 Walter Bright wrote:
 

 Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


 I did <g>.


 
 Right :) I don't agree.


 
 Let me explain why I think default public is a good idea.
 
 It reduces clutter in sample, example, and quick programs. Access
 security is an advanced feature, one that's invaluable for a complex
 project, but is just in the way for smaller ones.
 
 I don't mind at all when crafting a carefully designed, reusable module
 that 'private' needs to be explicit. It helps document the intention,
 and lends the impression that the designer did put some thought into the
 code.
 
 But when writing illustrative sample code, I feel that having to add in
 'public's is distracting from the point (unless, of course, the point is
 about how access control works!). I see this a lot in sample C++ code,
 and it is distracting, to me anyway.
 
 And it's just plain irritating when writing smaller programs where
 access control is quite irrelevant.


And it here I think you miss the point. When D as a language rather help in
writing small example programs, instead of making it easy and safe to write
large applications and libraries, how is then D supposed to take the
ultimate step? D has so much potential for writing large, powerful
applications and libraries, and D continously shoots it down. Illustrative
code should show the actual features making the language good to use in
larger projects (once they are there, they will contain much larger bodies
of code than all the smaller ones combined), not be a goal for the language
itself.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 12 2006
parent Dave <Dave_member pathlink.com> writes:
Lars Ivar Igesund wrote:

 Walter Bright wrote:
 

 Lars Ivar Igesund wrote:

 Walter Bright wrote:


 Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


 I did <g>.


 Right :) I don't agree.


 Let me explain why I think default public is a good idea.

 It reduces clutter in sample, example, and quick programs. Access
 security is an advanced feature, one that's invaluable for a complex
 project, but is just in the way for smaller ones.

 I don't mind at all when crafting a carefully designed, reusable module
 that 'private' needs to be explicit. It helps document the intention,
 and lends the impression that the designer did put some thought into the
 code.

 But when writing illustrative sample code, I feel that having to add in
 'public's is distracting from the point (unless, of course, the point is
 about how access control works!). I see this a lot in sample C++ code,
 and it is distracting, to me anyway.

 And it's just plain irritating when writing smaller programs where
 access control is quite irrelevant.


 
 And it here I think you miss the point. When D as a language rather help in
 writing small example programs, instead of making it easy and safe to write
 large applications and libraries, how is then D supposed to take the
 ultimate step? D has so much potential for writing large, powerful
 applications and libraries, and D continously shoots it down. Illustrative
 code should show the actual features making the language good to use in
 larger projects (once they are there, they will contain much larger bodies
 of code than all the smaller ones combined), not be a goal for the language
 itself.
 


It would take a lot of large changes to make D ill-suited to easily 
developed and concise example programs or utilities compared to any of 
its strongly type competitors. None of the recent import proposals come 
even close to doing that.

In fact, such large changes would probably do harm to both types of 
development because D as-is is almost perfect IMO. We're just trying to 
tune the import mechanism here, especially for use with the forthcoming 
huge and diverse libraries. :)
Jul 12 2006
prev sibling next sibling parent xs0 <xs0 xs0.com> writes:
Walter Bright wrote:

 Lars Ivar Igesund wrote:

 Walter Bright wrote:


 Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


 I did <g>.


 Right :) I don't agree.


 
 Let me explain why I think default public is a good idea.


For the general case (classes/functions/etc.), I'd say both private and 
public defaults have their advantages and disadvantages, so OK, but I'd 
still like you to reconsider imports.



 It reduces clutter in sample, example, and quick programs. Access 
 security is an advanced feature, one that's invaluable for a complex 
 project, but is just in the way for smaller ones.


In single-module programs, it doesn't matter either way
In multiple-module programs (both small and large), the clutter is 
greater than it would be if imports were private by default.



 And it's just plain irritating when writing smaller programs where 
 access control is quite irrelevant.


Exactly. Yet you force us to declare imports private as soon as more 
than one module is used.

You seem to miss the obvious fact that most imports serve a module's 
implementation, not its interface..


BTW, in any case neither the current "import foo" nor potential "public 
import foo" don't really indicate what they do, at least to me.. how about:

import foo;         // currently "private import foo;"
import/export foo;  // currently "import foo;"

Don't take that too seriously, but it would make things far more obvious...


xs0
Jul 12 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Wed, 12 Jul 2006 19:25:57 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Lars Ivar Igesund wrote:

 Walter Bright wrote:


 Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


 I did <g>.


  Right :) I don't agree.


 Let me explain why I think default public is a good idea.

 It reduces clutter in sample, example, and quick programs. Access  
 security is an advanced feature, one that's invaluable for a complex  
 project, but is just in the way for smaller ones.

 I don't mind at all when crafting a carefully designed, reusable module  
 that 'private' needs to be explicit. It helps document the intention,  
 and lends the impression that the designer did put some thought into the  
 code.

 But when writing illustrative sample code, I feel that having to add in  
 'public's is distracting from the point (unless, of course, the point is  
 about how access control works!). I see this a lot in sample C++ code,  
 and it is distracting, to me anyway.

 And it's just plain irritating when writing smaller programs where  
 access control is quite irrelevant.


Oh for Bob's sake ... you mean the primary purpose of D is to write sample  
programs and examples? How did I miss that!!?? I thought it was to be a  
real language to write commercial applications with rather than an  
educational tool/toy. Sorry I misunderstood.


-- 
Derek Parnell
Melbourne, Australia
Jul 12 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 Oh for Bob's sake ... you mean the primary purpose of D is to write 
 sample programs and examples? How did I miss that!!?? I thought it was 
 to be a real language to write commercial applications with rather than 
 an educational tool/toy. Sorry I misunderstood.


I didn't mean it's useful to make D a language to teach people about 
programming. I meant it's useful for teaching D to people.

It's not always true, but languages that are less wordy in their example 
code tend to be picked up faster. People's first projects in D aren't 
going to be large, complex, professional products. They'll want to just 
try it out on something simple. That bar should be as low as reasonable.
Jul 12 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 12 Jul 2006 12:05:22 -0700, Walter Bright  
<newshound digitalmars.com> wrote:

 Derek Parnell wrote:

 Oh for Bob's sake ... you mean the primary purpose of D is to write  
 sample programs and examples? How did I miss that!!?? I thought it was  
 to be a real language to write commercial applications with rather than  
 an educational tool/toy. Sorry I misunderstood.


 I didn't mean it's useful to make D a language to teach people about  
 programming. I meant it's useful for teaching D to people.

 It's not always true, but languages that are less wordy in their example  
 code tend to be picked up faster. People's first projects in D aren't  
 going to be large, complex, professional products. They'll want to just  
 try it out on something simple. That bar should be as low as reasonable.


Private imports wont have any affect on the size of single file examples  
and small first programs/projects.

Regan
Jul 12 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 Oh for Bob's sake ... you mean the primary purpose of D is to write 
 sample programs and examples? How did I miss that!!?? I thought it was 
 to be a real language to write commercial applications with rather 
 than an educational tool/toy. Sorry I misunderstood.


 
 I didn't mean it's useful to make D a language to teach people about 
 programming. I meant it's useful for teaching D to people.
 
 It's not always true, but languages that are less wordy in their example 
 code tend to be picked up faster. People's first projects in D aren't 
 going to be large, complex, professional products. They'll want to just 
 try it out on something simple. That bar should be as low as reasonable.


Really, how about Java? It is quite wordy from example programs to even 
the large projects, yet it has been thoroughly successful. D should be 
designed for mid and large projects, not small, simple ones.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 12 2006
parent Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:

 Walter Bright wrote:

 It's not always true, but languages that are less wordy in their 
 example code tend to be picked up faster. People's first projects in D 
 aren't going to be large, complex, professional products. They'll want 
 to just try it out on something simple. That bar should be as low as 
 reasonable.


 
 Really, how about Java? It is quite wordy from example programs to even 
 the large projects, yet it has been thoroughly successful.


Java is an exception. I find it wordy, though, and I've often heard that 
complaint about it. And yes, it's been successful. How successful would 
it have been without a billion dollar push behind it? Maybe it's 
successful in spite of the wordiness. No language is perfect, and people 
often settle for flaws because the good stuff outweighs it.

On the other hand, many terse languages have succeeded despite having no 
money behind them - C, Perl, Ruby, etc. Sometimes when I read the 
debates between static and dynamic typing, the real issue seems to be 
that often people just don't want to be bothered with typing in a type.

Cobol has clearly stepped over the line in wordiness, and APL has 
stepped over the line in terseness. I think D hits the sweet spot in 
between.


 D should be
 designed for mid and large projects, not small, simple ones.


People aren't going to get to a mid to large project with D if it is not 
going to be very usable for small ones.
Jul 12 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Thu, 13 Jul 2006 05:05:22 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Derek Parnell wrote:

 Oh for Bob's sake ... you mean the primary purpose of D is to write  
 sample programs and examples? How did I miss that!!?? I thought it was  
 to be a real language to write commercial applications with rather than  
 an educational tool/toy. Sorry I misunderstood.


 I didn't mean it's useful to make D a language to teach people about  
 programming. I meant it's useful for teaching D to people.

 It's not always true, but languages that are less wordy in their example  
 code tend to be picked up faster. People's first projects in D aren't  
 going to be large, complex, professional products. They'll want to just  
 try it out on something simple. That bar should be as low as reasonable.


I understand your desire to not 'frighten' new comers away. My concern is  
that your "low as reasonable" seems to encourage poor programming  
practices. Can you provide an example where the 'import' and 'visibility'  
ideas being brainstormed at the moment would force example code to look  
scary? At worst, someone might have to add 'public { ... }' somewhere.

-- 
Derek Parnell
Melbourne, Australia
Jul 12 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 On Thu, 13 Jul 2006 05:05:22 +1000, Walter Bright 

 It's not always true, but languages that are less wordy in their 
 example code tend to be picked up faster. People's first projects in D 
 aren't going to be large, complex, professional products. They'll want 
 to just try it out on something simple. That bar should be as low as 
 reasonable.


 
 I understand your desire to not 'frighten' new comers away. My concern 
 is that your "low as reasonable" seems to encourage poor programming 
 practices. Can you provide an example where the 'import' and 
 'visibility' ideas being brainstormed at the moment would force example 
 code to look scary? At worst, someone might have to add 'public { ... }' 
 somewhere.


Not exactly what you're after, but consider the Java hello world program:

   class HelloWorldApp {
     public static void main(String[] args) {
         System.out.println("Hello World!");
     }
   }

There's a reason for everything there, but it's a little off-putting. 
Consider the D version:

   import std.stdio;

   void main() {
      writefln("Hello World!");
   }

I can go straighter towards what I want to do, without detouring through 
all the other requirements Java puts on things that seem, with such a 
simple program, to be beside the point.

Just for fun, here's an Ada version:

   With STANDARD_IO;
   Use STANDARD_IO;
   Procedure HELLO_WORLD is begin
     Put("Hello world!");
   End HELLO_WORLD;

No thanks! <g>
Jul 12 2006
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 12 Jul 2006 17:03:11 -0700, Walter Bright wrote:


 Derek Parnell wrote:

 On Thu, 13 Jul 2006 05:05:22 +1000, Walter Bright 

 It's not always true, but languages that are less wordy in their 
 example code tend to be picked up faster. People's first projects in D 
 aren't going to be large, complex, professional products. They'll want 
 to just try it out on something simple. That bar should be as low as 
 reasonable.


 
 I understand your desire to not 'frighten' new comers away. My concern 
 is that your "low as reasonable" seems to encourage poor programming 
 practices. Can you provide an example where the 'import' and 
 'visibility' ideas being brainstormed at the moment would force example 
 code to look scary? At worst, someone might have to add 'public { ... }' 
 somewhere.


 
 Not exactly what you're after, but consider the Java hello world program:
 
    class HelloWorldApp {
      public static void main(String[] args) {
          System.out.println("Hello World!");
      }
    }
 
 There's a reason for everything there, but it's a little off-putting. 
 Consider the D version:
 
    import std.stdio;
 
    void main() {
       writefln("Hello World!");
    }


Thank you! This is exactly what I had hoped for, because the changes
discussed recently would not alter this example one iota. In fact, the
changes only start to kick in when programs get more complex, and that's
exactly when you need to introduce such protection concepts to D newcomers.
 

 I can go straighter towards what I want to do, without detouring through 
 all the other requirements Java puts on things that seem, with such a 
 simple program, to be beside the point.
 
 Just for fun, here's an Ada version:
 
    With STANDARD_IO;
    Use STANDARD_IO;
    Procedure HELLO_WORLD is begin
      Put("Hello world!");
    End HELLO_WORLD;
 
 No thanks! <g>


Ouch! And I just remembered what it would look like in COBOL (oh the
horror!)

Here it is in Euphoria (one line) ...

  puts(1, "Hello world!")

but now we digress because Euphoria's import (include) system is almost as
problematic as D's. In that language one can have independent third party
libraries clashing with each other just because you decided to include both
of them into your application, even if you never reference the clashing
members.

But back on track, the sample code in the D tutorials will have zero
changes in nearly every case, and minor changes in the others to explain
how the protection system can work in the coder's favour.
-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
13/07/2006 10:17:13 AM
Jul 12 2006
prev sibling next sibling parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 On Thu, 13 Jul 2006 05:05:22 +1000, Walter Bright

 It's not always true, but languages that are less wordy in their
 example code tend to be picked up faster. People's first projects in
 D aren't going to be large, complex, professional products. They'll
 want to just try it out on something simple. That bar should be as
 low as reasonable.


 I understand your desire to not 'frighten' new comers away. My concern
 is that your "low as reasonable" seems to encourage poor programming
 practices. Can you provide an example where the 'import' and
 'visibility' ideas being brainstormed at the moment would force
 example code to look scary? At worst, someone might have to add
 'public { ... }' somewhere.


 
 Not exactly what you're after, but consider the Java hello world program:
 
   class HelloWorldApp {
     public static void main(String[] args) {
         System.out.println("Hello World!");
     }
   }
 
 There's a reason for everything there, but it's a little off-putting.
 Consider the D version:
 
   import std.stdio;
 
   void main() {
      writefln("Hello World!");
   }


Changing the language syntax so that imports are private by default does
not change anything in either of those examples. Perhaps this is a
better example:

module gfx_subsystem:
  private import GUI;

  void init_gfx_system() { setvideomode(); clearbuffers(); ... }

module game_engine:
  (private) import gfx_subsystem, sound_subsystem;

  void init_engine() { init_gfx_system(); ... }

Here the developer of game_engine is really not interested in GUI
widgets. If gfx_subsystem publicly imported the GUI stuff, the namespace
of game_engine would be totally poisoned. Then why should it be the
default behavior? After all, this is a very common pattern in
applications programming. Using public imports also makes the
development process a lot more time consuming. Think of all the
irrelevant proposals the IDE shows when auto-completing code in a
poisoned namespace.

-- 
Jari-Matti
Jul 12 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Jari-Matti Mäkelä wrote:

 Walter Bright wrote:

 Not exactly what you're after, but consider the Java hello world program:

   class HelloWorldApp {
     public static void main(String[] args) {
         System.out.println("Hello World!");
     }
   }

 There's a reason for everything there, but it's a little off-putting.
 Consider the D version:

   import std.stdio;

   void main() {
      writefln("Hello World!");
   }


 
 Changing the language syntax so that imports are private by default does
 not change anything in either of those examples.


True. But what I think goes too far is requiring hello world to look like:

   import std.stdio;

   public void main() {
      std.stdio.writefln("Hello World!");
   }

It's not like it's wrong to design D that way, it's just off-putting. 
Simple things should be simple.
Jul 14 2006
next sibling parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Walter Bright wrote:

 Jari-Matti Mäkelä wrote:

 Walter Bright wrote:

 Not exactly what you're after, but consider the Java hello world
 program:

   class HelloWorldApp {
     public static void main(String[] args) {
         System.out.println("Hello World!");
     }
   }

 There's a reason for everything there, but it's a little off-putting.
 Consider the D version:

   import std.stdio;

   void main() {
      writefln("Hello World!");
   }


 Changing the language syntax so that imports are private by default does
 not change anything in either of those examples.


 
 True. But what I think goes too far is requiring hello world to look like:
 
   import std.stdio;
 
   public void main() {
      std.stdio.writefln("Hello World!");
   }
 
 It's not like it's wrong to design D that way, it's just off-putting.
 Simple things should be simple.


Agreed.

Although I don't think anyone particularly was suggesting that it should
be a default. According to
<http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution> a
majority of active members only want to extend the import syntax so that
old programs would work exactly as they do now and new programs would
have better control over their namespaces. The 'static import' + some
aliasing would be more than enough to fix this but many coders are so
lazy (including me) they want import to support aliasing directly. ;)

Making the imports private wouldn't break any existing tutorial code
either since it requires at least two user modules for private imports
to have any effect. Most code snippets I've seen feature only one.

-- 
Jari-Matti
Jul 14 2006
parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Jari-Matti Mäkelä wrote:

 Although I don't think anyone particularly was suggesting that it should
 be a default. According to
 <http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution> a
 majority of active members only want to extend the import syntax so that
 old programs would work exactly as they do now and new programs would
 have better control over their namespaces. The 'static import' + some
 aliasing would be more than enough to fix this but many coders are so
 lazy (including me) they want import to support aliasing directly. ;)



that wiki. No-one has come up yet with an elegant way to provide only
FQN access with the 'as'-syntax. Can't we have both. :)

-- 
Jari-Matti
Jul 14 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
On Fri, 14 Jul 2006 11:54:53 -0700, Jari-Matti Mäkelä  
<jmjmak utu.fi.invalid> wrote:


 Jari-Matti Mäkelä wrote:

 Although I don't think anyone particularly was suggesting that it should
 be a default. According to
 <http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution> a
 majority of active members only want to extend the import syntax so that
 old programs would work exactly as they do now and new programs would
 have better control over their namespaces. The 'static import' + some
 aliasing would be more than enough to fix this but many coders are so
 lazy (including me) they want import to support aliasing directly. ;)



 that wiki. No-one has come up yet with an elegant way to provide only
 FQN access with the 'as'-syntax. Can't we have both. :)



Really?

import spec.lib.spec as spec.lib.spec;

Doesn't that work for you?

I think all this has been pretty thoroughly covered, Jari-Matti.

-JJR
Jul 14 2006
parent =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
John Reimer wrote:

 On Fri, 14 Jul 2006 11:54:53 -0700, Jari-Matti Mäkelä
 <jmjmak utu.fi.invalid> wrote:
 

 Jari-Matti Mäkelä wrote:

 Although I don't think anyone particularly was suggesting that it should
 be a default. According to
 <http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution> a
 majority of active members only want to extend the import syntax so that
 old programs would work exactly as they do now and new programs would
 have better control over their namespaces. The 'static import' + some
 aliasing would be more than enough to fix this but many coders are so
 lazy (including me) they want import to support aliasing directly. ;)



 that wiki. No-one has come up yet with an elegant way to provide only
 FQN access with the 'as'-syntax. Can't we have both. :)


 
 
 Really?
 
 import spec.lib.spec as spec.lib.spec;
 
 Doesn't that work for you?


Of course :)
Jul 14 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Walter Bright wrote:

 True. But what I think goes too far is requiring hello world to look like:
 
   import std.stdio;
 
   public void main() {
      std.stdio.writefln("Hello World!");
   }
 
 It's not like it's wrong to design D that way, it's just off-putting. 


It's like going to the doctor, and he tells you you should eat whole 
wheat bread instead of white bread. Of course, he's right. His reasoning 
is sound, and backed by solid scientific evidence. But you just like 
white bread better, and since the grocery stores are well stocked with 
white bread, it obviously sells well. Any baker wanting to sell bread 
should pay attention <g>.

But the stores also have a line of whole wheat, for those that are 
willing to eat what's good for them.
Jul 14 2006
prev sibling next sibling parent kris <foo bar.com> writes:
Walter Bright wrote:

 Derek Parnell wrote:
 

 On Thu, 13 Jul 2006 05:05:22 +1000, Walter Bright


 It's not always true, but languages that are less wordy in their 
 example code tend to be picked up faster. People's first projects in 
 D aren't going to be large, complex, professional products. They'll 
 want to just try it out on something simple. That bar should be as 
 low as reasonable.



 I understand your desire to not 'frighten' new comers away. My concern 
 is that your "low as reasonable" seems to encourage poor programming 
 practices. Can you provide an example where the 'import' and 
 'visibility' ideas being brainstormed at the moment would force 
 example code to look scary? At worst, someone might have to add 
 'public { ... }' somewhere.


 
 
 Not exactly what you're after, but consider the Java hello world program:
 
   class HelloWorldApp {
     public static void main(String[] args) {
         System.out.println("Hello World!");
     }
   }
 
 There's a reason for everything there, but it's a little off-putting. 
 Consider the D version:
 
   import std.stdio;
 
   void main() {
      writefln("Hello World!");
   }
 
 I can go straighter towards what I want to do, without detouring through 
 all the other requirements Java puts on things that seem, with such a 
 simple program, to be beside the point.
 
 Just for fun, here's an Ada version:
 
   With STANDARD_IO;
   Use STANDARD_IO;
   Procedure HELLO_WORLD is begin
     Put("Hello world!");
   End HELLO_WORLD;
 
 No thanks! <g>



And the concise & completely safe D version:

    import std.stdio io;

    void main() {
       io.writefln("Hello World!");
    }

However, this example imports only the one module, so use of the unsafe 
import might be ok for such things?

On the other hand, someone pointed out that habits are formed from just 
such examples (was it Derek?). One should perhaps be careful to ensure 
the safe approach is /encouraged/ right from the start, if such habits 
are indeed formed in this manner? That's a question for another time.



 I can go straighter towards what I want to do, without detouring
 through all the other requirements Java puts on things that seem,
 with such a simple program, to be beside the point.


If concise language is considered beneficial, then D would likely gain 
from a less wordy safe-import (in terms of overal usage).



 I can go straighter towards what I want to do, without detouring
 through all the other requirements Java puts on things that seem,
 with such a simple program, to be beside the point.


Then why detour with an extra alais statement?

     import lib.db.model.odbc odbc;

     void main() {
        auto db = odbc.open ("db");
     }

versus this:

     static import lib.db.model.odbc;
     alias lib.db.model.odbc odbc;

     void main() {
        auto db = odbc.open ("db");
     }

To echo your own sentiment, No thanks! <g>


the latter looks rather like the Ada version.


   With STANDARD_IO;
   Use STANDARD_IO;
   Procedure HELLO_WORLD is begin
     Put("Hello world!");
   End HELLO_WORLD;
Jul 12 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 Derek Parnell wrote:
 

 On Thu, 13 Jul 2006 05:05:22 +1000, Walter Bright


 It's not always true, but languages that are less wordy in their 
 example code tend to be picked up faster. People's first projects in 
 D aren't going to be large, complex, professional products. They'll 
 want to just try it out on something simple. That bar should be as 
 low as reasonable.



 I understand your desire to not 'frighten' new comers away. My concern 
 is that your "low as reasonable" seems to encourage poor programming 
 practices. Can you provide an example where the 'import' and 
 'visibility' ideas being brainstormed at the moment would force 
 example code to look scary? At worst, someone might have to add 
 'public { ... }' somewhere.




(I've been trying to catch up on this NG, but the number of unreads is 
growing faster than I can keep up, so I don't know what the Current 
Community Consensus on syntax exactly is right now, so I'm guessing the 
syntax here.)


 Not exactly what you're after, but consider the Java hello world program:
 
   class HelloWorldApp {
     public static void main(String[] args) {
         System.out.println("Hello World!");
     }
   }
 
 There's a reason for everything there, but it's a little off-putting. 


Yes, from a teacher's point of view, the above is just depressing. On 
first day, you can't even explain the words because the needed concepts 
are pure greek to the audience anyway. I've actually been there a few times.


 Consider the D version:
 
   import std.stdio;
 
   void main() {
      writefln("Hello World!");
   }


D is a lot nicer. Now compare the above with:


     import std.stdio as io;

     void main() {
         io.writefln("Hello World!");
     }


Sure it's more to type! (Six letters, a dot and two spaces.)

 From an educational point of view, this is actually better than current 
D, because it now becomes perfectly clear /why/ we have the import line 
in the first place!!! It's needed for the writefln.

Additionally, I've seen students struggling with what comes from which 
library, why we need so many libraries, etc. All this would become much 
clearer if the students keep seeing "which words don't belong to the 
language itself and come from a library instead".


 I can go straighter towards what I want to do, without detouring through 
 all the other requirements Java puts on things that seem, with such a 
 simple program, to be beside the point.


I can, however, see this:

     import std.stdio as io;

     void main() {
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
         io.writefln("Hello World!");
     }

Now it's three letters more per line, so in a 100kloc program this means 
300kB extra on the hard disk, and some wear on your fingertips.

I admit we could have a means of using unqualified names, sure. But that 
should be the programmer's own choice!

     import std.stdio;                 // works like currently
     import std.stdio as foo;          // into foo namespace only
     import std.stdio.writefln;        // only writefln gets imported
     import std.stdio.writefln as wrt; // please implement this too

(Oh, and "as" is better than a space, if you ask me. No question.)
Jul 13 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 13 Jul 2006 10:22:41 +0300, Georg Wrede wrote:


 
 I can, however, see this:
 
      import std.stdio as io;
 
      void main() {
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
      }


Just half joking, but what you can do even now is this ...

      import std.stdio;
      alias std.stdio.writefln w;
 
      void main() {
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
      }

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
14/07/2006 10:35:41 AM
Jul 13 2006
parent reply Rémy Mouëza <ray.jay.ay.moueza DoNtSpAm.gmail.com> writes:
In article <1dqjwdjjptjso.kw68mtrh7ba9.dlg 40tude.net>, Derek Parnell says...

On Thu, 13 Jul 2006 10:22:41 +0300, Georg Wrede wrote:


 
 I can, however, see this:
 
      import std.stdio as io;
 
      void main() {
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
          io.writefln("Hello World!");
      }


Just half joking, but what you can do even now is this ...

      import std.stdio;
      alias std.stdio.writefln w;
 
      void main() {
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
          w("Hello World!");
      }


And what about the with keyword ?
:   import std.stdio as io;
:
:   void main () 
:   {
:       with ( io )
:       {
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:           writefln ( "Hello World!" );
:       }
:   }

Any thoughts about it ?
Jul 14 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 15 Jul 2006 10:39:42 +1000, Rémy Mouëza  
<ray.jay.ay.moueza DoNtSpAm.gmail.com> wrote:


 And what about the with keyword ?


Because we don't know what the 'with' is referring to ...

    import std.stdio as io;

    void main ()
    {
        with ( io )
        {
            writefln ( somedata );
        }
    }

Is the 'io' a prefix to 'writefln' or 'somedata'? How would the human  
reader know that?

-- 
Derek Parnell
Melbourne, Australia
Jul 14 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Lars Ivar Igesund wrote:

 Walter Bright wrote:


 Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


 I did <g>.


 Right :) I don't agree.


 
 Let me explain why I think default public is a good idea.
 
 It reduces clutter in sample, example, and quick programs. Access 
 security is an advanced feature, one that's invaluable for a complex 
 project, but is just in the way for smaller ones.
 
 I don't mind at all when crafting a carefully designed, reusable module 
 that 'private' needs to be explicit. It helps document the intention, 
 and lends the impression that the designer did put some thought into the 
 code.


I think you'll get most of us to agree for access control in general and 
my experience with the language bares that out.

For imports though, many of us feel that private shouldn't need to be 
explicit because we don't want the side-effects (by default) we may have 
little control over for such a sweeping statement as 'import' (that may 
import thousands of symbols, and that may increase geometrically as more 
top level modules import their own, etc...).


 
 But when writing illustrative sample code, I feel that having to add in 
 'public's is distracting from the point (unless, of course, the point is 
 about how access control works!). I see this a lot in sample C++ code, 
 and it is distracting, to me anyway.
 
 And it's just plain irritating when writing smaller programs where 
 access control is quite irrelevant.
Jul 12 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:

 Lars Ivar Igesund wrote:
 

 Walter Bright wrote:


 Lars Ivar Igesund wrote:


 Well, who did ever say that was a good idea, everything public by
 default? ;)


 I did <g>.



 Right :) I don't agree.


 
 
 Let me explain why I think default public is a good idea.
 
 It reduces clutter in sample, example, and quick programs. Access 
 security is an advanced feature, one that's invaluable for a complex 
 project, but is just in the way for smaller ones.


Hmm. So D is becoming an educational language, like Pascal.


 I don't mind at all when crafting a carefully designed, reusable module 
 that 'private' needs to be explicit. It helps document the intention, 
 and lends the impression that the designer did put some thought into the 
 code.


If somebody wants a public import, then /that/ intention should be 
documented -- not the other way around, right?


 But when writing illustrative sample code, I feel that having to add in 
 'public's is distracting from the point (unless, of course, the point is 
 about how access control works!). I see this a lot in sample C++ code, 
 and it is distracting, to me anyway.


Problem is, readers of illustrative code tend to copy them in their own 
first programs, then make similar code, and in time larger pieces of 
code. They frequently miss the transition point where they should change 
their behavior (in this case, to start using "private"), and the end 
result is large code with small-code practices. Very bad, and you can 
see it all over the place!


 And it's just plain irritating when writing smaller programs where 
 access control is quite irrelevant.


Code should be written so implicitly public imports are not needed!

If I import some high-level module which in turn imports some low-level 
module, and I happen to need stuff from that low-level module too, I 
sure as hell better import that explicitly in my program.

Code has to be clear, deliberate, and lucid. This is not achieved by 
good-luck chained imports. And definitely not by good-luck chained 
implicit or invisible, or even gratuituous imports.
Jul 12 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Georg Wrede wrote:

 Walter Bright wrote:

 But when writing illustrative sample code, I feel that having to add
 in 'public's is distracting from the point (unless, of course, the
 point is about how access control works!). I see this a lot in sample
 C++ code, and it is distracting, to me anyway.


 
 Problem is, readers of illustrative code tend to copy them in their own
 first programs, then make similar code, and in time larger pieces of
 code. They frequently miss the transition point where they should change
 their behavior (in this case, to start using "private"), and the end
 result is large code with small-code practices. Very bad, and you can
 see it all over the place!


A good point.


 And it's just plain irritating when writing smaller programs where
 access control is quite irrelevant.


 
 Code should be written so implicitly public imports are not needed!
 
 If I import some high-level module which in turn imports some low-level
 module, and I happen to need stuff from that low-level module too, I
 sure as hell better import that explicitly in my program.


I think when two modules are somewhat tightly coupled, public import
should be used instead of manually importing everything all over again.
It's pretty analogous to the package management systems of modern Linux
distros: installing (importing) a package (module) also installs
(imports) its dependencies.

IMO the biggest issue here is that even practice shows that private
imports are much much more common. It's quiet natural since the main
principle of OOP languages is to keep public interfaces as minimal as
possible. It's annoying as hell to publicly import everything. At first
it looks like it's much easier to code that way. After ~50 classes the
future still looks quite bright. But then you import that simple
helloworld-widget from GUI or some other huge library (I'm talking about
QT 4.2 sized GUI here, not DUI). Bang - 50+ name conflicts. Why did this
happen? Because too much functionality was exposed to the child modules.
If only that graphical arbitrary precision math library object hadn't
imported that 3rd party implementation of sound stream. Importing to a
namespace (import foo as bar) can be used as a workaround, but it really
isn't the solution. It should only be used in some "rare" situations,
where refactoring otherwise becomes too expensive. (at least that's how
I see it)

Specifying the correct protection attribute for every import isn't a
trivial task at all. I think one should spend significant amount of time
considering the rationale behind every import. The task can be
impossibly difficult for even experienced programmers and therefore
should be made as "safe" (=does not poison namespace) as possible.
Luckily importing privately by default fixes this.

-- 
Jari-Matti
Jul 12 2006
parent kris <foo bar.com> writes:
Jari-Matti Mäkelä wrote:

 Georg Wrede wrote:
 

Walter Bright wrote:


But when writing illustrative sample code, I feel that having to add
in 'public's is distracting from the point (unless, of course, the
point is about how access control works!). I see this a lot in sample
C++ code, and it is distracting, to me anyway.


Problem is, readers of illustrative code tend to copy them in their own
first programs, then make similar code, and in time larger pieces of
code. They frequently miss the transition point where they should change
their behavior (in this case, to start using "private"), and the end
result is large code with small-code practices. Very bad, and you can
see it all over the place!


 
 
 A good point.
 
 

And it's just plain irritating when writing smaller programs where
access control is quite irrelevant.


Code should be written so implicitly public imports are not needed!

If I import some high-level module which in turn imports some low-level
module, and I happen to need stuff from that low-level module too, I
sure as hell better import that explicitly in my program.


 
 
 I think when two modules are somewhat tightly coupled, public import
 should be used instead of manually importing everything all over again.
 It's pretty analogous to the package management systems of modern Linux
 distros: installing (importing) a package (module) also installs
 (imports) its dependencies.
 
 IMO the biggest issue here is that even practice shows that private
 imports are much much more common. It's quiet natural since the main
 principle of OOP languages is to keep public interfaces as minimal as
 possible. It's annoying as hell to publicly import everything. At first
 it looks like it's much easier to code that way. After ~50 classes the
 future still looks quite bright. But then you import that simple
 helloworld-widget from GUI or some other huge library (I'm talking about
 QT 4.2 sized GUI here, not DUI). Bang - 50+ name conflicts. Why did this
 happen? Because too much functionality was exposed to the child modules.
 If only that graphical arbitrary precision math library object hadn't
 imported that 3rd party implementation of sound stream. Importing to a
 namespace (import foo as bar) can be used as a workaround, but it really
 isn't the solution. It should only be used in some "rare" situations,
 where refactoring otherwise becomes too expensive. (at least that's how
 I see it)
 
 Specifying the correct protection attribute for every import isn't a
 trivial task at all. I think one should spend significant amount of time
 considering the rationale behind every import. The task can be
 impossibly difficult for even experienced programmers and therefore
 should be made as "safe" (=does not poison namespace) as possible.
 Luckily importing privately by default fixes this.
 



All good points.

In the FWIW category, Mango makes all imports private expect for those 
that expose symbols used somewhere important; such as arguments to class 
constructors. The idea was first proposed by Chris Nicholson-Sauls, and 
it is one I found to pay big dividends overall (thanks to Chris).

I noticed that an import count was performed on Mango, and the public 
imports were 18% or something? That seems high to me, so perhaps we've 
been slacking ;D

Either way, all imports in Mango are (or should be) explicit in terms of 
public, private, package, etc. When it comes to code, it is often useful 
to explicitly convey intent behind an action.
Jul 12 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Lars Ivar Igesund wrote:

 Walter Bright wrote:


 Lars Ivar Igesund wrote:

 Well, who did ever say that was a good idea, everything public by
 default? ;)


 I did <g>.


 Right :) I don't agree.


 
 Let me explain why I think default public is a good idea.
 
 It reduces clutter in sample, example, and quick programs. Access 
 security is an advanced feature, one that's invaluable for a complex 
 project, but is just in the way for smaller ones.
 
 I don't mind at all when crafting a carefully designed, reusable module 
 that 'private' needs to be explicit. It helps document the intention, 
 and lends the impression that the designer did put some thought into the 
 code.
 
 But when writing illustrative sample code, I feel that having to add in 
 'public's is distracting from the point (unless, of course, the point is 
 about how access control works!). I see this a lot in sample C++ code, 
 and it is distracting, to me anyway.
 
 And it's just plain irritating when writing smaller programs where 
 access control is quite irrelevant.


I agree. An interesting example is that many small classes in C++ STL 
programs use 'struct' instead of 'class' because it defaults to public.
You can find 'struct' all over the Boost libraries! Default public must 
be worth something.

But I don't think this argument is applicable to imports.
(a) For quick and dirty programs, and for most examples, you don't care 
if imports are public or not.
(b) Since a module exists in its own file, I don't think the consistency 
argument carries much weight. Functions in an executable file or DLL are 
only public if you add 'extern' to them (the program as a whole defaults 
to 'private'). For modules, we're talking about 'default transitory 
public' which I think is quite different to 'default public'. I can see 
over my neighbours fence, but that doesn't mean I can see over *his* 
neighbours fence (even though he can).

Changing to default private would break code, but it might not break a 
whole lot of existing code.
(a) I suspect that the majority of quick and dirty imports don't 
actually care if they are public or private. It's not as if every 
existing instance of 'import' would need to be changed to 'public import'.
(b) Some existing broken code would be fixed! I keep finding I need to 
put 'private' in front of 'import' in existing modules, to solve name 
conflicts.

And any code that would break could be fixed very quickly.

Please consider this issue again. There is still a window to change it 
before 1.0.
Jul 12 2006
next sibling parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
"Don Clugston" wrote:

[ default public ]


 An interesting example is that many small classes in C++ STL programs use 
 'struct' instead of 'class' because it defaults to public.
 You can find 'struct' all over the Boost libraries! Default public must be 
 worth something.


This is mainly because a specialised keyword is missing.

These structs are neither used as "real classes"
(to be inherited or having virtual functions)
not as "value classes" but mostly for metaprogramming.


In some cases it is because of lazyness to write one more line.

/Pavel
Jul 12 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:

 Walter Bright wrote:

 And it's just plain irritating when writing smaller programs where 
 access control is quite irrelevant.


 I agree. An interesting example is that many small classes in C++ STL 
 programs use 'struct' instead of 'class' because it defaults to public.
 You can find 'struct' all over the Boost libraries! Default public must 
 be worth something.


If you write classes like:

	struct Point { int x, y; }

It's just irritating to have to write it:

	struct Point { public int x, y; }

Quite a lot of classes have all public members.


 But I don't think this argument is applicable to imports.
 (a) For quick and dirty programs, and for most examples, you don't care 
 if imports are public or not.


That's a good point.


 (b) Since a module exists in its own file, I don't think the consistency 
 argument carries much weight. Functions in an executable file or DLL are 
 only public if you add 'extern' to them (the program as a whole defaults 
 to 'private').


Minor nit: 'export', not 'extern'.


 For modules, we're talking about 'default transitory 
 public' which I think is quite different to 'default public'. I can see 
 over my neighbours fence, but that doesn't mean I can see over *his* 
 neighbours fence (even though he can).
 
 Changing to default private would break code, but it might not break a 
 whole lot of existing code.
 (a) I suspect that the majority of quick and dirty imports don't 
 actually care if they are public or private. It's not as if every 
 existing instance of 'import' would need to be changed to 'public import'.
 (b) Some existing broken code would be fixed! I keep finding I need to 
 put 'private' in front of 'import' in existing modules, to solve name 
 conflicts.
 
 And any code that would break could be fixed very quickly.
 
 Please consider this issue again. There is still a window to change it 
 before 1.0.


I think you've made a pretty good case for it.
Jul 12 2006
next sibling parent Brad Anderson <brad dsource.org> writes:
Walter Bright wrote:

 Don Clugston wrote:

 Walter Bright wrote:

 And it's just plain irritating when writing smaller programs where
 access control is quite irrelevant.


 I agree. An interesting example is that many small classes in C++ STL
 programs use 'struct' instead of 'class' because it defaults to public.
 You can find 'struct' all over the Boost libraries! Default public
 must be worth something.


 
 If you write classes like:
 
     struct Point { int x, y; }
 
 It's just irritating to have to write it:
 
     struct Point { public int x, y; }
 
 Quite a lot of classes have all public members.
 

 But I don't think this argument is applicable to imports.
 (a) For quick and dirty programs, and for most examples, you don't
 care if imports are public or not.


 
 That's a good point.
 

 (b) Since a module exists in its own file, I don't think the
 consistency argument carries much weight. Functions in an executable
 file or DLL are only public if you add 'extern' to them (the program
 as a whole defaults to 'private').


 
 Minor nit: 'export', not 'extern'.
 

 For modules, we're talking about 'default transitory public' which I
 think is quite different to 'default public'. I can see over my
 neighbours fence, but that doesn't mean I can see over *his*
 neighbours fence (even though he can).

 Changing to default private would break code, but it might not break a
 whole lot of existing code.
 (a) I suspect that the majority of quick and dirty imports don't
 actually care if they are public or private. It's not as if every
 existing instance of 'import' would need to be changed to 'public
 import'.
 (b) Some existing broken code would be fixed! I keep finding I need to
 put 'private' in front of 'import' in existing modules, to solve name
 conflicts.

 And any code that would break could be fixed very quickly.

 Please consider this issue again. There is still a window to change it
 before 1.0.


 
 I think you've made a pretty good case for it.


oh SWEET !!!!!

BA
Jul 12 2006
prev sibling next sibling parent "John Reimer" <terminal.node gmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e93hja$1sfu$1 digitaldaemon.com...

 Don Clugston wrote:

 Walter Bright wrote:

 And it's just plain irritating when writing smaller programs where 
 access control is quite irrelevant.


 I agree. An interesting example is that many small classes in C++ STL 
 programs use 'struct' instead of 'class' because it defaults to public.
 You can find 'struct' all over the Boost libraries! Default public must 
 be worth something.


 If you write classes like:

 struct Point { int x, y; }

 It's just irritating to have to write it:

 struct Point { public int x, y; }

 Quite a lot of classes have all public members.


 But I don't think this argument is applicable to imports.
 (a) For quick and dirty programs, and for most examples, you don't care 
 if imports are public or not.


 That's a good point.


 (b) Since a module exists in its own file, I don't think the consistency 
 argument carries much weight. Functions in an executable file or DLL are 
 only public if you add 'extern' to them (the program as a whole defaults 
 to 'private').


 Minor nit: 'export', not 'extern'.


 For modules, we're talking about 'default transitory public' which I 
 think is quite different to 'default public'. I can see over my 
 neighbours fence, but that doesn't mean I can see over *his* neighbours 
 fence (even though he can).

 Changing to default private would break code, but it might not break a 
 whole lot of existing code.
 (a) I suspect that the majority of quick and dirty imports don't actually 
 care if they are public or private. It's not as if every existing 
 instance of 'import' would need to be changed to 'public import'.
 (b) Some existing broken code would be fixed! I keep finding I need to 
 put 'private' in front of 'import' in existing modules, to solve name 
 conflicts.

 And any code that would break could be fixed very quickly.

 Please consider this issue again. There is still a window to change it 
 before 1.0.


 I think you've made a pretty good case for it.



Once again, the case was made based on C++.  That certainly makes it 
difficult to convince you any other way, and leaves a lot of non-C++ people 
incapable of ever making a strong argument for D changes.  You seem to have 
a strong attachment to the C++ community still.  There's a lot of peer 
pressure there, I guess?

Oh well, hopefully everything works out.

-JJR
Jul 12 2006
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Don Clugston wrote:

 Walter Bright wrote:

 And it's just plain irritating when writing smaller programs where 
 access control is quite irrelevant.


 I agree. An interesting example is that many small classes in C++ STL 
 programs use 'struct' instead of 'class' because it defaults to public.
 You can find 'struct' all over the Boost libraries! Default public 
 must be worth something.


 
 If you write classes like:
 
     struct Point { int x, y; }
 
 It's just irritating to have to write it:
 
     struct Point { public int x, y; }
 
 Quite a lot of classes have all public members.
 

 But I don't think this argument is applicable to imports.
 (a) For quick and dirty programs, and for most examples, you don't 
 care if imports are public or not.


 
 That's a good point.
 

 (b) Since a module exists in its own file, I don't think the 
 consistency argument carries much weight. Functions in an executable 
 file or DLL are only public if you add 'extern' to them (the program 
 as a whole defaults to 'private').


 
 Minor nit: 'export', not 'extern'.
 

 For modules, we're talking about 'default transitory public' which I 
 think is quite different to 'default public'. I can see over my 
 neighbours fence, but that doesn't mean I can see over *his* 
 neighbours fence (even though he can).

 Changing to default private would break code, but it might not break a 
 whole lot of existing code.
 (a) I suspect that the majority of quick and dirty imports don't 
 actually care if they are public or private. It's not as if every 
 existing instance of 'import' would need to be changed to 'public 
 import'.
 (b) Some existing broken code would be fixed! I keep finding I need to 
 put 'private' in front of 'import' in existing modules, to solve name 
 conflicts.

 And any code that would break could be fixed very quickly.

 Please consider this issue again. There is still a window to change it 
 before 1.0.


 
 I think you've made a pretty good case for it.


Wow, this sounds very good :)
Jul 12 2006
prev sibling next sibling parent Frank Benoit <keinfarbton nospam.xyz> writes:
Walter Bright schrieb:

 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.


I don't think so. Where are the millions lines of code, that would
break? At the moment, this is an issue that is against writing them.

Making things private is a defensive change. You can solve every problem
with adding 'public' and the compiler will tell you every problematic
place. Other is the default public. The modules writer does no get
problems, but the user of the module will can get them from a
implementation detail.
Jul 11 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
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
Jul 11 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
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
Jul 11 2006
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
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
Jul 11 2006
prev sibling next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
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. 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.


I'd have to agree with Walter. However, making "static" import the 
default might be a good compromise?

L.
Jul 11 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 

 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.


Nonsense, of course it's not too late! In fact, for this change in 
particular, it's quite easy to write a trivial script that can easily 
convert from one syntax to the other, without errors. So if you want to 
argue about this proposal, do so regarding it's merits only, not 
compatibility.

So about the consistency issue: I too think consistency and 
orthogonality are very important (maybe even more than you :P ), but the 
key thing to notice here is that a (private) import is not defining new 
members of a module. It's not creating a new entity or entities. I view 
an import as very different from defining a class, struct, variable, 
function, etc., and therefore I don't find it inconsistent for the 
default protection to be different.

In fact, I even have some doubts about the whole thing of imports having 
protection attributes in the first place. It wouldn't strike me as odd 
if import was protectionless, working only the same as the current 
"private import", and that the functionality of the current "public 
import" were achieved in some other way like "alias somemodule.*;" or 
"aliasimport somemodule;" or something like that.

=> One clue that an import is different from any other declarations with 
protection attributes, is that its names go to a secondary namespace. 
That's inconsistency right there. (if you view the imports the same as 
the other things)


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 11 2006
parent Dave <Dave_member pathlink.com> writes:
Bruno Medeiros wrote:

 Walter Bright wrote:

 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.


 
 Nonsense, of course it's not too late! In fact, for this change in 
 particular, it's quite easy to write a trivial script that can easily 
 convert from one syntax to the other, without errors. So if you want to 
 argue about this proposal, do so regarding it's merits only, not 
 compatibility.
 
 So about the consistency issue: I too think consistency and 
 orthogonality are very important (maybe even more than you :P ), but the 
 key thing to notice here is that a (private) import is not defining new 
 members of a module. It's not creating a new entity or entities. I view 
 an import as very different from defining a class, struct, variable, 
 function, etc., and therefore I don't find it inconsistent for the 
 default protection to be different.
 
 In fact, I even have some doubts about the whole thing of imports having 
 protection attributes in the first place. It wouldn't strike me as odd 
 if import was protectionless, working only the same as the current 
 "private import", and that the functionality of the current "public 
 import" were achieved in some other way like "alias somemodule.*;" or 
 "aliasimport somemodule;" or something like that.
 
 => One clue that an import is different from any other declarations with 
 protection attributes, is that its names go to a secondary namespace. 
 That's inconsistency right there. (if you view the imports the same as 
 the other things)
 


Well said - you beat me to it <g> Especially the last point, which is a 
great argument against strict consistency and orthogonality for imports 
because as declarations some of their properties stand alone.
Jul 11 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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".)
Jul 11 2006
parent reply Bill Baxter <Bill_member pathlink.com> writes:
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
Jul 11 2006
next sibling parent BCS <BCS pathlink.com> writes:
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
Jul 11 2006
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
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
Jul 11 2006
prev sibling next sibling parent xs0 <xs0 xs0.com> writes:
 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
Jul 11 2006
prev sibling next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
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
Jul 11 2006
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jul 11 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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*.
Jul 11 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
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
Jul 11 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Derek Parnell wrote:

 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?


Several reasons.

  - The syntax looks explicit enough for the programmer to honestly 
assume that the only import is to the specified namespace.

  - Doing stuff behind the back is Bad Manners.

  - Importing to both would not alleviate the problem of namespace 
pollution.

  - Who'd understand the error messages about name clashes?

  - Any outsider would really consider this a grave beginner bug from 
the compiler writer.
Jul 12 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 12 Jul 2006 10:45:09 +0300, Georg Wrede wrote:


 Derek Parnell wrote:

 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?


 
 Several reasons.
 
   - The syntax looks explicit enough for the programmer to honestly 
 assume that the only import is to the specified namespace.


Hmmm ... I read "import std.stdio as io" as saying import std.stdio and
from here on in the text of this module, when 'io' is used assume that
'std.stdio' was meant instead. In other words, I see this as saying that
'io' is an optional, alternative reference to 'std.stdio'. I don't read
'io' as being a namespace, but just an alias for std.stdio.

However if the synatx was "import std.stdio into io" that would make me
think of 'io' as a namespace into which the stuff in std.stdio was placed
for look up.


   - Doing stuff behind the back is Bad Manners.


Automatically looking into the imported files for matching names is bad
manners? Not for me it isn't. In fact it seems down right neighbourly.


   - Importing to both would not alleviate the problem of namespace 
 pollution.


And by "namespace pollution" you are referring to the increased possibility
of duplicating names in the same lookup scope level, right? Of course it
wouldn't but that's not what it was trying to do.


   - Who'd understand the error messages about name clashes?


Messages like ...

  myfile(44): Cannot find an accessible matching function 'foo'.


   - Any outsider would really consider this a grave beginner bug from 
 the compiler writer.


I don't think there is much evidence of that yet, but may by I'm not an

behaviour is correctly documented one can simply get educated instead of
assuming a beginner compiler writer.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
12/07/2006 5:54:32 PM
Jul 12 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

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


There are a lot more D users than people who post here. I hear from them 
when I make a change that breaks their code, and they are rarely happy 
about it.
Jul 12 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 12 Jul 2006 00:39:31 -0700, Walter Bright wrote:


 Bill Baxter wrote:

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


 
 There are a lot more D users than people who post here. I hear from them 
 when I make a change that breaks their code, and they are rarely happy 
 about it.


I can understand that. If I may be so bold as to say that you really ought
to telegraph your intentions in detail before implementing them. Especially
stuff which has the potential to break otherwise conformant code.

So ... what are you planning for imports and when might we see any changes?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
12/07/2006 5:47:28 PM
Jul 12 2006
parent Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 On Wed, 12 Jul 2006 00:39:31 -0700, Walter Bright wrote:
 

 Bill Baxter wrote:

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


 There are a lot more D users than people who post here. I hear from them 
 when I make a change that breaks their code, and they are rarely happy 
 about it.


 
 I can understand that.


I also want to add that it's considered generally true that if you hear 
a complaint from one person, there's probably another 25 who have the 
same complaint but don't bother to complain - they just go away.



 If I may be so bold as to say that you really ought
 to telegraph your intentions in detail before implementing them. Especially
 stuff which has the potential to break otherwise conformant code.
 
 So ... what are you planning for imports and when might we see any changes?


I'll take Sean's suggestion and let things cool down a bit first. 
Decisions made when feelings are running high tend to be rotten ones <g>.
Jul 12 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

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


 
 There are a lot more D users than people who post here. I hear from them 
 when I make a change that breaks their code, and they are rarely happy 
 about it.


Assuming you're talking about 'private import by default'.

If you bold and highlight it in the change log and the general download 
page I would think that would be enough. How hard could it be to stick 
'public ' in front of ones imports? Especially since they can keep using 
v0.162 until they make the change?
Jul 12 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

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


 
 There are a lot more D users than people who post here. I hear from them 
 when I make a change that breaks their code, and they are rarely happy 
 about it.


Let me just say that I am *not* one of those people. I've been letting 
my more esteemed colleagues (Kris, Sean, Lars, et al) do the talking. I 
just want to remind you, Walter, that these are those who have written 
the most code, at least publicly, in your language. Perhaps you should 
lend more weight to their arguments because of this.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
Jul 12 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Bill Baxter 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 (Not opposed, in favor)


 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 (Opposed)



-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 12 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Bruno Medeiros wrote:

 Bill Baxter 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 (Not opposed, in favor)


  Not me either.


 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 (Opposed)


Not me either.
Jul 12 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 Dave wrote:

 Walter, I think what most are getting at here is that the 'as' syntax 
 just seems cleaner and more efficient from a coding and maintenance POV.

 If it's easy to implement, then I say go for it. If nothing else, 
 people can still use 'explicit' aliasing. I argue that 'as' will 
 actually be quicker for newbies to grasp (*especially* when they see 
 it in example code), and my sense is that it will be a boon to 
 maintenance because it generally won't end-up buried in the middle of 
 a module like many aliases would be. It's not like alias will be a 
 wasted feature - most prominently it will be used for storage types; 
 it just feels more 'natural' that way.




 
 (I'm pretty tired so forgive me for being succinct/unclear)
 

 I think you're saying that this is not a discussion about 
 functionality, but about aesthetics. I agree with that.

 A couple of people have brought up the alias-in-the-middle thing:

 1) If it's in the middle because it's in a nested scope, then it only 
 applies for the duration of that scope. Presumably, it would be easily 
 visible to anyone looking at that scope.

 2) I think we can all agree that if it is at module scope in the 
 middle, that is probably bad coding style - especially if there are 
 forward references to it.


 
 Certainly.  However, it's been my experience that the vast majority of 
 programmers on any given project tend not to be particularly scrupulous 
 with their coding style, and code quality tends to degenerate over time. 
  Therefore, I believe that any means available to encourage good coding 
 style and ease readability is worth considering quite carefully.  Having 
 literally tossed old projects in the trash because the cost of 
 maintenance was actually higher than a complete rewrite, I really can't 
 stress this point enough.  But please note that I'm not suggesting a 
 language or tool should in any way "dumb itself down" for the user, only 
 that aesthetics plays a significant role in determining whether a 
 particular feature or technique will be successful.
 


Exactly - I couldn't have said it better.


 3) The with-import-as won't eliminate bad coding style with aliases. 
 One can still plop an alias down in the middle of the module.


 
 I do believe that bad code typically results from a few common causes:
 
 * The programmer honestly doesn't know any better.  Often he's a novice 
 or simply hasn't been exposed to the level of programming required for 
 the task assigned.
 
 * The programmer knows better but is in a hurry and doesn't care about 
 cutting a few corners.  He'll go back and fix it when there's more time. 
  And that time will never be available.
 


Great point.


 In both of these cases, language aesthetics makes a difference.  In the 
 first case, a mentor could suggest an alternate approach.  For this to 
 succeed the learning programmer must be able to remember the solution 
 and it must be fairly easy to execute.  If not, the programmer is 
 destined to become a member of the second category, as he now knows 
 better but finds some excuse not to use the technique anyway, often 
 because he can't remember the details or because it requires too much 
 typing.  In both cases, having support for the suggested technique built 
 into the language or tool is ideal, as it presents both a syntactical 
 reminder and a simpler way to accomplish the task than the programmer 
 would be inclined to use otherwise.  Finally, if the technique *looks 
 better* than another method and it's used pervasively, it will typically 
 be followed by others (the broken window problem).
 


Exactly.


 4) At least with aliases, they need to be defined within the module. 
 This means one can do a simple search of one source file to find any 
 aliases.


 
 Given the size of some of the source files I've seen, even a directed 
 keyword search may take some time.  This simply doesn't compare to a 
 glance at the import line.
 

 Let's look a bit at the aesthetics:

     with foo.bar import
         abc as def,
         ghi as jkl,
         mno;

     import very.long.name as N;
 vs:
     static import foo.bar;
         alias foo.bar.abc def;
         alias foo.bar.ghi jkl;
         alias foo.bar.mno mno;

     import very.long.name;
         alias very.long.name N;


 Yes, the latter is more typing. If one was to do this a lot, it can 
 get annoying. But is it going to be done a lot? I think that is the 
 crux of the matter.


 
 Assuming the language stays as-is, I believe the aliasing will likely be 
 limited to instances where collisions occur, as the technique is easy to 
 forget and requires a lot of typing.  I expect this will also lead to 
 maintenance issues as library upgrades cause symbol collisions and such.
 


Again, exactly.


 As for qualifiers themselves, I expect the typical module name to be at 
 least two levels deep:
 
     import product.package.module;
 
 and often more for large libraries.  Mango is a useful reference here, 
 and serves to support this assertion.
 

 P.S. There are other possible syntaxes:

     import foo.bar
     {    def = abc,
         jkl = ghi,
         mno,
     }


 
 As long as the syntax is aesthetically pleasing and 
 logically/structurally similar to Kris' proposal, I won't bicker over 
 minutiae.  That isn't too say I'm overly fond of the syntax you just 
 suggested, but I do understand that a slightly different syntax may 
 parse more easily or  better fit the 'feel' of the language as a whole.
 


The exact implementation I leave to Walter (if the statement still 
starts with '[private] import' ;))


 
 Sean
Jul 11 2006
prev sibling next sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Walter Bright wrote:

 But is it going to be done a lot? 


assuming we get static import i think this will get done a lot
static import foo.bar.m;
alias foo.bar.m m;

which I would prefere to write as
import foo.bar.m as m;

I think the among the C++ crowd the people who refuse to use using 
namespace would use the more qualified form and thous who use using 
wont. As I think D will attract many C++ programmers and for and against 
using is an argument i here a lot (many on the different sides where i 
come from) i think the D language will appeal more to C++ programmers if 
as is introduced as it look cleaner and the more programmer a language 
can appeal to the more it will bee used.
Jul 11 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Dave wrote:

 Walter, I think what most are getting at here is that the 'as' syntax 
 just seems cleaner and more efficient from a coding and maintenance POV.

 If it's easy to implement, then I say go for it. If nothing else, 
 people can still use 'explicit' aliasing. I argue that 'as' will 
 actually be quicker for newbies to grasp (*especially* when they see 
 it in example code), and my sense is that it will be a boon to 
 maintenance because it generally won't end-up buried in the middle of 
 a module like many aliases would be. It's not like alias will be a 
 wasted feature - most prominently it will be used for storage types; 
 it just feels more 'natural' that way.


 
 I think you're saying that this is not a discussion about functionality, 
 but about aesthetics. I agree with that.
 
 A couple of people have brought up the alias-in-the-middle thing:
 
 1) If it's in the middle because it's in a nested scope, then it only 
 applies for the duration of that scope. Presumably, it would be easily 
 visible to anyone looking at that scope.
 
 2) I think we can all agree that if it is at module scope in the middle, 
 that is probably bad coding style - especially if there are forward 
 references to it.
 
 3) The with-import-as won't eliminate bad coding style with aliases. One 
 can still plop an alias down in the middle of the module.
 
 4) At least with aliases, they need to be defined within the module. 
 This means one can do a simple search of one source file to find any 
 aliases.
 
 Let's look a bit at the aesthetics:
 
     with foo.bar import
         abc as def,
         ghi as jkl,
         mno;
 
     import very.long.name as N;
 vs:
     static import foo.bar;
         alias foo.bar.abc def;
         alias foo.bar.ghi jkl;
         alias foo.bar.mno mno;
 
     import very.long.name;
         alias very.long.name N;
 
 
 Yes, the latter is more typing. If one was to do this a lot, it can get 
 annoying. But is it going to be done a lot? I think that is the crux of 
 the matter.
 
 P.S. There are other possible syntaxes:
 
     import foo.bar
     {    def = abc,
         jkl = ghi,
         mno,
     }


If we go that route, then that syntax would be fine by me as well!

I don't like starting with 'with/from' because that 'hides' 'import' or 
'private import' which is what D users are used to when they scan a page 
for imports.
Jul 11 2006
prev sibling next sibling parent kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:
 

 The use of alias, regarding imports, should very likely be kept to a 
 bare minimum in anything other than Q&D development. Ideally zero.


 
 
 I really don't understand your pov. I can't help but think you regard 
 alias as like C++'s #define:
 
     alias foo bar;
     #define bar foo
 
 Such #define's I would agree are a terrible hack that don't belong in 
 professional code. But aliasing isn't like that, it's a sane and 
 well-behaved replacement.
 

 It's like the use of goto ~ use it where it can really help, but 
 otherwise consider alternatives instead. I don't know what kind of 
 development-scales you have in mind for D, but I'll happily testify 
 that a boatload of aliases littering the imports would have no place 
 in any project I'm responsible for; nor in those of the people I 
 learned from. Here's why:

 Quantities of alias do little but complicate ones comprehension of the 
 code. Having a second-step (import then alias) is not only messy for 
 each import, it does nothing to /encourage/ smart usage of namespace 
 seperation. In fact, the extra step will likely discourage everyone 
 but the diehards from using anything but the current global namespace, 
 and we'll end up right back at square one.


 
 
 With the "static import", there is no longer any possibility of name 
 collisions, so we're not at square one. With no aliases, fully qualified 
 module contents lookup will be needed.



That's assuming anyone would use it? Who's gonna do that when you insist 
that (a) they have to always use the FQN for safe imports or (b) use an 
alias along with every static import?

Suppose people actually used static-import? We'd start migrating to the 
shortest import paths possible to avoid the long names, or have an alias 
sitting beside every import.

These two belong together ~ the idea is to /encourage/ people to use 
this safer alternative, not turn them away.



 At that point, the language would be lacking. And why? This is all 
 about maturity and usability of the language in specific areas. Why 
 the rollback to something that can be considered "arcane" instead?


 
 
 I don't see it as arcane or a workaround. Symbolic aliasing is a very 
 powerful feature - yet it's very simple.



Perhaps you ought to stop for a moment and take a look at all the people 
here asking you to combine these features together? Then go back over 
the last two years and just count how many posts there are about this 
one specific aspect: import. Do we really have to beg? Does D go where 
the community wants it to? Take a look at /all/ these posts ~ please?



 Hey ~ if you'd actually roll in the changes, I'd be happy to make them 
 myself ... I'd add both selective import and the "as" variation ~ a 
 flexible combination to handle all cases, including the one Derek 
 astutely pointed out. No aliases required by the user:

 // import as we know it today, and with a required prefix "locale."
 import lib.text.locale;
 import lib.text.locale as locale;

 // selective import of one entity, and alternatively with an alias
 import lib.text.locale.Time;
 import lib.text.locale.Time as otherTime;

 ==================================


 
 
 But those *are* aliases. It's just using a different keyword, "as" 
 instead of "alias", and a slightly rearranged syntax. So what's the 
 difference between:
 
 import lib.text.locale.Time as otherTime;
 
 and:
 
 alias lib.text.locale.Time otherTime;
 
 ? Absolutely none, unless I am totally misunderstanding your proposal.



Under the covers? Does it matter?



 Okay. Let's reflect for a moment?

 The functionality is there, but the syntax could probably be better? 
 There's a number of other posts proposing the use of "with" and so on, 
 which look rather promising (from Kirk & Derek):

 with lib.text.locale import Time, Date;

 Seems pretty darned clear what's going on there. Seems to me that's a 
 much more user-focused solution for selective imports. Let's combine 
 this with a means to import an entire module under a prefix, as we've 
 previously seen:

      // import as we know it today
 import lib.text.locale;
 auto time = new Time;

      // "locale." prefix required (great for IFTI modules)
 import lib.text.locale as locale;
 auto utc = locale.utcTime();
 auto dst = locale.daylightSavings();

      // selective import
 with lib.text.locale import Time, Date;
 auto time = new Time;
 auto date = new Date;

      // selective import with alias
 with lib.text.locale import Time, Date as MyDate;
 auto time = new Time;
 auto date = new MyDate;

 ==================================

 How about it?


 
 
       // "locale." prefix required (great for IFTI modules)
 static import lib.text.locale;
 alias lib.text.locale locale;
 auto utc = locale.utcTime();
 auto dst = locale.daylightSavings();
 
      // selective import
 static import lib.text.locale;
 alias lib.text.locale.Time Time;
 alias lib.text.locale.Date Date;
 auto time = new Time;
 auto date = new Date;
 
      // selective import with alias
 static import lib.text.locale;
 alias lib.text.locale.Time Time;
 alias lib.text.locale.Date MyDate;
 auto time = new Time;
 auto date = new MyDate;
 
 These are semantically identical. The "static import" is a bit ugly 
 looking, ok. It's a little wordier, ok. But it does work and produces 
 exactly the results you asked for.



And at the cost of making life harder for anyone who has to work on a 
large-scale project containing hundreds or thousands of modules. Without 
being disrespectful, I have to ask when was the last time you worked on 
a large-scale application with more than three people involved? Now how 
about several million lines with 500 engineers? Do you really want them 
plonking aliases all over the place when it's basically trivial for the 
compiler to deal with this in a clean and precise manner? Isn't this 
wehre you want D to be? Or is it intended to compete with Python only? 
(and IIRC python actually has a better import system).

Skip to the next section if you want to avoid overflowing frustration.

I don't get it, Walter. I really don't. I would have thought you'd be 
more that considerate toward making things easy for the end-user, but 
you seem to be insisting they take multiple steps with something that 
pretty much /every/ module will do multiple times: import other modules. 
To do so in the safest manner possible should be made as easy for the 
user as possible. Not in some manner that discourages anyone from using 
the safe approach.



 Let's harken back to the special regexp syntax I tried out a few months 
 ago. It was a bit of syntactic sugar that reduced typing significantly. 
 But it was soundly rejected by the community as adding complexity (in 
 the form of more language to learn) while actually adding little to no 
 extra power.



Just don't know how I can explain this to you in a way that you'll 
understand; But I'll give it one last try:

* Regex is used rarely in modules. Even in apps with heavy regex usage, 
the functionality tends to get wrapped anyway. On the other hand, import 
is used in pretty much every module. It's something that's almost always 
there, and the safest manner of using import should obviously be made 
easy to use, easy to follow, and easy to maintain.

* Regex is perfectly suited to library functionality. One cannot do that 
with import ~ it's part of the module declaration. Isn't that the case?

* Embedding Regex in the language itself tend to reduce the motivation 
to provide alternate implementations. The Template Regex is just one 
such example, which you proudly displayed at a presentation. I don't 
think import can really be compared to this aspect either; can it?

The embedded regex was rejected for at least the latter two reasons, and 
not because it added extra complexity to learn the language. Given that 
import will be used mutliple times by pretty much every single module, 
and Regex by almost zero in comparison, it would appear overtly reckless 
to consider them as equivalent in any form or manner.

======= idea =========

Perhaps we should count how many imports there are in the current D 
language base, and then compare that to the number of import std.Regex? 
What would you guess? Perhaps 5000 to 1? Maybe 100,000 to 1? Perhaps 
more? How many does it have to be?

I truly hope this makes the distinction clear enough for you?

======================



 The "with" and "as" syntaxes add no power - they just save a little 
 typing at the expense of adding more complexity to the grammar. Is that 
 a worthwhile tradeoff? I don't know, but my inclination is to be 
 conservative about such things.
 
 I suggest trying out the "static import" for a while. See how it works 
 and looks.


I earnestly suggest you consider how many people are currently and have 
been asking for you to address this concern, and to place overall 
usability of daily-language usage above whatever is stopping you from 
considering this beyond the need for yet more alias usage.

Think about it ... import is used /all/ the time. Perhaps an average of 
three times per module? Would you rather make the safe method of import 
hard to use, or easy to use?
Jul 09 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 17:59:36 +1000, Walter Bright  =

<newshound digitalmars.com> wrote:


 kris wrote:

 The use of alias, regarding imports, should very likely be kept to a =




 =


 bare minimum in anything other than Q&D development. Ideally zero.


 I really don't understand your pov. I can't help but think you regard =


 =


 alias as like C++'s #define:

 	alias foo bar;
 	#define bar foo


I'm hope I'm not messing up Kris' words here but I think he is saying th=
at  =

we need to cut down on the amount of typing and reading people *must* do=
  =

in a program. Keep it to a minimum. Try and work the syntax so that the =
 =

common and mandatory things are short, easy, and intuitive to do. Make t=
he  =

unusual and 'special' things have more detail in the syntax.


 Such #define's I would agree are a terrible hack that don't belong in =


 =


 professional code. But aliasing isn't like that, it's a sane and  =



 well-behaved replacement.


I don't think we are talking so much about the semantics of alias but mo=
re  =

about how to code it efficiently.


 With the "static import", there is no longer any possibility of name  =



 collisions, so we're not at square one. With no aliases, fully qualifi=


ed  =


 module contents lookup will be needed.


"static import" is not an intuitive syntax. I doesn't mean much until on=
e  =

explicitly learns it.



  // import as we know it today, and with a required prefix "locale."
 import lib.text.locale;
 import lib.text.locale as locale;
  // selective import of one entity, and alternatively with an alias
 import lib.text.locale.Time;
 import lib.text.locale.Time as otherTime;
  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 But those *are* aliases. It's just using a different keyword, "as"  =



 instead of "alias", and a slightly rearranged syntax. So what's the  =



 difference between:

 import lib.text.locale.Time as otherTime;

 and:

 alias lib.text.locale.Time otherTime;

 ? Absolutely none, unless I am totally misunderstanding your proposal.=



Not really. Firstly "import ... as ...;" is a single statement but "impo=
rt  =

...; alias ...;" is two which can be separated and 'hidden' in the  =

clutter. Secondly, the proposed syntax is not redundant - the module nam=
e  =

is typed in only once.


 The "static import" is a bit ugly looking, ok. It's a little wordier, =


 =


 ok. But it does work and produces exactly the results you asked for.


*NOT* ok. Why encourage mediocrity. You can do us and future D coders a =
 =

favour by giving us a better syntax than something that is admittedly ug=
ly  =

and too wordy.

-- =

Derek Parnell
Melbourne, Australia
Jul 09 2006
parent reply David Medlock <noone nowhere.com> writes:
Derek Parnell wrote:


 
 I'm hope I'm not messing up Kris' words here but I think he is saying 
 that  we need to cut down on the amount of typing and reading people 
 *must* do  in a program. Keep it to a minimum. Try and work the syntax 
 so that the  common and mandatory things are short, easy, and intuitive 
 to do. Make the  unusual and 'special' things have more detail in the 
 syntax.
 


I 100% agree.  The usual cases should be implicit, and the corner cases 
explicit.

I would really like private aliases in any case, Walter.

-DavidM
Jul 09 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
David Medlock wrote:

 Derek Parnell wrote:
 

 I'm hope I'm not messing up Kris' words here but I think he is saying 
 that  we need to cut down on the amount of typing and reading people 
 *must* do  in a program. Keep it to a minimum. Try and work the syntax 
 so that the  common and mandatory things are short, easy, and 
 intuitive to do. Make the  unusual and 'special' things have more 
 detail in the syntax.


 
 I 100% agree.  The usual cases should be implicit, and the corner cases 
 explicit.


But *are* they the usual case? As far as I can tell, Python is the only 
significant language that allows aliasing of import names (though the 
Python manual calls it "binding"). (We'll set aside the C++ #define 
trick as not a reasonable method.) I haven't seen it used in Python 
code, though I admit I haven't seen much Python code.

That's why I suggest just trying it for a while. Kris' original concerns 
are met with the combination of 'static import' (I know, I know, should 
think of some better keyword combination) and 'alias'. Syntax changes 
should be done conservatively - if there's an existing way to do it, it 
has to be used a lot to justify special syntax for it.

Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, but 
loops are so very, very common that special syntactic sugar for it has 
proven to be a big win.

D already has a lot of syntax in it. We should be very careful about 
adding more; not every convenience should have its own syntactic sugar.
Jul 10 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 David Medlock wrote:

 Derek Parnell wrote:


 I'm hope I'm not messing up Kris' words here but I think he is saying 
 that  we need to cut down on the amount of typing and reading people 
 *must* do  in a program. Keep it to a minimum. Try and work the 
 syntax so that the  common and mandatory things are short, easy, and 
 intuitive to do. Make the  unusual and 'special' things have more 
 detail in the syntax.


 I 100% agree.  The usual cases should be implicit, and the corner 
 cases explicit.


 
 But *are* they the usual case? As far as I can tell, Python is the only 
 significant language that allows aliasing of import names (though the 
 Python manual calls it "binding"). (We'll set aside the C++ #define 
 trick as not a reasonable method.) I haven't seen it used in Python 
 code, though I admit I haven't seen much Python code.
 
 That's why I suggest just trying it for a while. Kris' original concerns 
 are met with the combination of 'static import' (I know, I know, should 
 think of some better keyword combination) and 'alias'. Syntax changes 
 should be done conservatively - if there's an existing way to do it, it 
 has to be used a lot to justify special syntax for it.
 
 Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, but 
 loops are so very, very common that special syntactic sugar for it has 
 proven to be a big win.


I'm not sure what exactly Kris said, but imports are ubiquitous. Not 
used as much as loops of course, but they are used in every program.

The goto also kind of equates with 'alias' in that goto's and alias's 
will be stuck almost anywhere in the code while (by convention) imports 
are at top. So there's an encouragment of good coding practices and 
maintenance element to this too.


 
 D already has a lot of syntax in it. We should be very careful about 
 adding more; not every convenience should have its own syntactic sugar.


I agree, but this will be a major convenience, imho.

The proposal here

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39967
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39973

seems to meet this criteria:

a) address all of Kris' concerns (if not Kris, pipe in here).
b) backward compatible.
c) can be implemented w/o significanly changing the current compiler (I 
think) other than for the import statement additions.
d) is consistent with how import + alias works now.
e) are a significant convenience.
f) keep the visual continuity of import statements for maintenance purposes.
g) encourage good coding practices with regards to imports and aliasing.

- Dave
Jul 10 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Dave wrote:

 g) encourage good coding practices with regards to imports and aliasing.
 


In the long run, this may be "listed last but certainly not least". 
Debugging other people's code will be hard enough without having to grep 
for imported symbol aliases everywhere.
Jul 10 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Dave wrote:

 Walter Bright wrote:

 D already has a lot of syntax in it. We should be very careful about 




adding more; not every convenience should have its own syntactic sugar.

 I agree, but this will be a major convenience, imho.

 The proposal here

 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39967
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39973

 seems to meet this criteria:

 a) address all of Kris' concerns (if not Kris, pipe in here).
 b) backward compatible.
 c) can be implemented w/o significanly changing the current compiler 


(I think) other than for the import statement additions.

 d) is consistent with how import + alias works now.
 e) are a significant convenience.
 f) keep the visual continuity of import statements for maintenance 


purposes.

 g) encourage good coding practices with regards to imports and aliasing.

 - Dave


Taking Walter's criteria from Lionello's post:


 Each idea goes through a gauntlet of:
 1) is lack of this idea turning users away from D


Right now, I don't know. Based on the response of several long-time 
users and many in this newsgroup, it probably will once more complex 
projects are attempted, especially libraries.


 2) how much power it adds


It adds the ability to import specific symbols - a quite powerful 
addition to import I think.


 3) how much complexity it adds


Not a lot for the programmer. It could actually remove a large amount of 
complexity for large projects. It doesn't change how import or alias 
work now so it doesn't add any complexity if not used.


 4) is it consistent with the rest of D


Yes.


 5) how hard is it to implement


It combines the current import and alias with what you already have in 
mind for 'static import'.


 6) how does it rank in importance against all the other ideas


 From the response over this weekend, I'd say "NEAR THE TOP".
Jul 10 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Dave wrote:

 I'm not sure what exactly Kris said, but imports are ubiquitous.
 Not used as much as loops of course, but they are used in every program.


Yes, they are ubiquitous. But the renaming of imported symbols? I'm not 
convinced that is at all ubiquitous, or that it is very desirable in any 
but unusual cases.



  > 2) how much power it adds
 
 It adds the ability to import specific symbols - a quite powerful 
 addition to import I think.


But that power already exists. The discussion is now about whether two 
statements should be combined into one or not. The power is the same.
Jul 10 2006
next sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 Dave wrote:
 

 I'm not sure what exactly Kris said, but imports are ubiquitous.


 
  > Not used as much as loops of course, but they are used in every program.
 
 Yes, they are ubiquitous. But the renaming of imported symbols? I'm not 
 convinced that is at all ubiquitous, or that it is very desirable in any 
 but unusual cases.


??

I suspect you are very confused about what is actually being asked for. 
Is that the case? Perhaps you'd like to note what it is that you think 
is being proposed?



  > 2) how much power it adds

 It adds the ability to import specific symbols - a quite powerful 
 addition to import I think.


 
 
 But that power already exists. 


One can import only specific symbols at this time? Really?



 The discussion is now about whether two 
 statements should be combined into one or not. The power is the same.



Again, please refer to Sean's post from yesterday.
Jul 10 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
kris wrote:

 Walter Bright wrote:

 Dave wrote:


 I'm not sure what exactly Kris said, but imports are ubiquitous.


  > Not used as much as loops of course, but they are used in every 
 program.

 Yes, they are ubiquitous. But the renaming of imported symbols? I'm 
 not convinced that is at all ubiquitous, or that it is very desirable 
 in any but unusual cases.


 
 ??
 
 I suspect you are very confused about what is actually being asked for. 
 Is that the case? Perhaps you'd like to note what it is that you think 
 is being proposed?


I'm beginning to feel like the focus is slipping a bit as well. 
However, the current issue of contention seems to be whether or not 
aliasing package/module names to something a bit more concise will be a 
common practice.  I assert that it will be, particularly if D gets 
something akin to "static import" where names must be fully-qualified. 
But the only crystal ball I can offer are the few nontrivial libraries 
that have been written for D (such as Mango) combined with experience 
and a general sense of how I expect to do things in the future.


 The discussion is now about whether two statements should be combined 
 into one or not. The power is the same.


 
 Again, please refer to Sean's post from yesterday.


As this thread has become quite extensive, I believe this is the post 
Kris is referring to:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39893


Sean
Jul 10 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 Walter Bright wrote:

 Dave wrote:


 I'm not sure what exactly Kris said, but imports are ubiquitous.


  > Not used as much as loops of course, but they are used in every 
 program.

 Yes, they are ubiquitous. But the renaming of imported symbols? I'm 
 not convinced that is at all ubiquitous, or that it is very desirable 
 in any but unusual cases.


 
 ??
 
 I suspect you are very confused about what is actually being asked for. 
 Is that the case? Perhaps you'd like to note what it is that you think 
 is being proposed?


You prefer:

	with Foo import bar as abc;

instead of:

	static import Foo;
	alias Foo.bar abc;



  > 2) how much power it adds
 It adds the ability to import specific symbols - a quite powerful 
 addition to import I think.


 But that power already exists. 


 One can import only specific symbols at this time? Really?


Import does not import names into the current namespace. It imports them 
into a secondary namespace, that is looked in *only* if the name isn't 
found in the current namespace. Alias can then cherry-pick specific 
symbols out of that secondary namespace and put them in the current 
namespace, possibly renaming them along the way. (Python's documentation 
calls that "binding" a name into the local symbol table, but it's the 
same thing.)

With 'static import', the names aren't even put into the secondary 
namespace. Unaliased, they can only be accessed as FQN's. An alias can 
then be used to bind individual symbols into the current namespace.

(*) And yes, you can still access the other names in the static import 
via FQN's. A couple posters thought that might be a problem, but:
1) I doubt many are going to accidentally type in a FQN;
2) FQN's are not going to produce name collisions unless you happen to 
name your symbols the same as the topmost package name, which is just 
not realistically going to be a problem.



 The discussion is now about whether two statements should be combined 
 into one or not. The power is the same.


 Again, please refer to Sean's post from yesterday.


I did (thanks for the direct link, Sean). The two proposals are 
semantically identical (*), and I don't see anything in Sean's post to 
indicate otherwise. It seems to me that Sean agreed that the difference 
is aesthetic, not functional.
Jul 11 2006
next sibling parent Paolo Invernizzi <arathorn NOSPAM_fastwebnet.it> writes:
Walter Bright wrote:


 Import does not import names into the current namespace. It imports them 
 into a secondary namespace, that is looked in *only* if the name isn't 
 found in the current namespace. Alias can then cherry-pick specific 
 symbols out of that secondary namespace and put them in the current 
 namespace, possibly renaming them along the way.


This is the best explanation of import I've seen so far! It made the 
current import semantic crystal clear. I suggest to cut-n-past it in the 
documentation.

---
Paolo
Jul 11 2006
prev sibling next sibling parent reply Bill Baxter <Bill_member pathlink.com> writes:
In article <e8vife$14p6$1 digitaldaemon.com>, Walter Bright says...


(*) And yes, you can still access the other names in the static import 
via FQN's. A couple posters thought that might be a problem, but:
1) I doubt many are going to accidentally type in a FQN;
2) FQN's are not going to produce name collisions unless you happen to 
name your symbols the same as the topmost package name, which is just 
not realistically going to be a problem.


Does that mean if I do

static import std.string;
alias std.string str;

Then there will trouble if I have a variable named 'std'?

That seems like that could be a source of trouble to me.  But maybe I've
misunderstood what you're saying.

Regards,
Bill
Jul 11 2006
parent Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 In article <e8vife$14p6$1 digitaldaemon.com>, Walter Bright says...
 

 (*) And yes, you can still access the other names in the static import 
 via FQN's. A couple posters thought that might be a problem, but:
 1) I doubt many are going to accidentally type in a FQN;
 2) FQN's are not going to produce name collisions unless you happen to 
 name your symbols the same as the topmost package name, which is just 
 not realistically going to be a problem.


 
 Does that mean if I do
 
 static import std.string;
 alias std.string str;
 
 Then there will trouble if I have a variable named 'std'?
 
 That seems like that could be a source of trouble to me.  But maybe I've
 misunderstood what you're saying.


The code:

   int std;
   import std.string;

Gives:

   test.d(2): import test.std conflicts with test.std at test.d(1)

Just like you can't do:

   int std;
   long std;
Jul 11 2006
prev sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:

 I suspect you are very confused about what is actually being asked 
 for. Is that the case? Perhaps you'd like to note what it is that you 
 think is being proposed?


 
 
 You prefer:
 
     with Foo import bar as abc;
 
 instead of:
 
     static import Foo;
     alias Foo.bar abc;
 


As I suspected, you've been thoroughly confused by the sheer variety of 
options. What /I've/ been asking can be broken down into two parts:

part 1.

import lib.text.locale.convert as convert;

This imports all of the convert module symbols, and makes them available 
via a "locale." prefix. This is equivalent to your "static import" in 
conjunction with a relevant alias.

Replace the keyword "as" with ':' or '=' as desired.

-------------

Part 2.

This second aspect is entirely optional. It came about based on your 
initial suggestion, and imports distinct symbols instead of all:

import lib.text.locale.convert.Converter;

For those who want to rename it at the same time, append the "as" 
syntax. The rename might be used to resolve the conflicts within phobos, 
for example. Again this selective-import is secondary ~ that should have 
been made clear from the beginning. It would be wonderful to have this 
selective-import along with the former style, but given the current 
circumstances I'd say it can happily be dropped in favour of the former.

---------------



 

  > 2) how much power it adds
 It adds the ability to import specific symbols - a quite powerful 
 addition to import I think.


 But that power already exists. 


 One can import only specific symbols at this time? Really?


 
 
 Import does not import names into the current namespace. It imports them 
 into a secondary namespace, that is looked in *only* if the name isn't 
 found in the current namespace. Alias can then cherry-pick specific 
 symbols out of that secondary namespace and put them in the current 
 namespace, possibly renaming them along the way. (Python's documentation 
 calls that "binding" a name into the local symbol table, but it's the 
 same thing.)
 
 With 'static import', the names aren't even put into the secondary 
 namespace. Unaliased, they can only be accessed as FQN's. An alias can 
 then be used to bind individual symbols into the current namespace.


I see; and this will encourage developers to use the safer approach?



 
 (*) And yes, you can still access the other names in the static import 
 via FQN's. A couple posters thought that might be a problem, but:
 1) I doubt many are going to accidentally type in a FQN;
 2) FQN's are not going to produce name collisions unless you happen to 
 name your symbols the same as the topmost package name, which is just 
 not realistically going to be a problem.
 
 

 The discussion is now about whether two statements should be combined 
 into one or not. The power is the same.






Yes, it is. But not for the reasons you think. You clearly feel it's all 
about aesthetics, for something that will be used rarely.

I feel it's more to do with ease of use, ease of maintainablity, and 
ease of comprehension at a glance.

Furthermore, I feel it is not something that will be used rarely at all. 
Instead, the safe import should be used at /all/ times by those who wish 
to avoid the otherwise inevitable potential for namespace collisions.

This latter observation basically dictates that commercial software 
houses should not use the existing import, given its notable 
susceptibility to namespace collisions in anything other than small 
projects. Instead, they should use the /safe/ import at all times. 
However, you insist they should then either use FQS at all times, or 
alias every one of those safe imports.

Yes, I understand that you feel this aspect is utter nonsense. But then, 
compared to some people here, your experience in such things is not 
necessarily the most applicable ~ how can you possibly expect it to be?

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?

Anyone would think we were trying to sabotage the language, when instead 
we're trying to get it into the shape needed for us to introduce it 
within the corporate realm.
Jul 11 2006
next sibling parent "John Reimer" <terminal.node gmail.com> writes:
"kris" <foo bar.com> wrote in message 
news:e8votm$1e76$1 digitaldaemon.com...

 Walter Bright wrote:

 kris wrote:

 I suspect you are very confused about what is actually being asked for. 
 Is that the case? Perhaps you'd like to note what it is that you think 
 is being proposed?



 You prefer:

     with Foo import bar as abc;

 instead of:

     static import Foo;
     alias Foo.bar abc;


 As I suspected, you've been thoroughly confused by the sheer variety of 
 options. What /I've/ been asking can be broken down into two parts:

 part 1.

 import lib.text.locale.convert as convert;

 This imports all of the convert module symbols, and makes them available 
 via a "locale." prefix. This is equivalent to your "static import" in 
 conjunction with a relevant alias.


I want to note a correction here.  Kris means "This imports all of the 
convert module symbols, and makes them available via 'convert.' prefix."

A little mistake... but just so people don't get confused. :)

-JJR
Jul 11 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.



 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).
Jul 11 2006
next sibling parent reply kris <foo bar.com> writes:
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.
Jul 11 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jul 11 2006
next sibling parent reply kris <foo bar.com> writes:
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*
Jul 11 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
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
Jul 11 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Regan Heath wrote:

 On Tue, 11 Jul 2006 04:16:29 -0700, kris <foo bar.com> wrote:

 Walter Bright wrote:

 kris wrote:

 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


I'm not getting that impression either. You (kris) were right about the 
problem of a lack of FQN import, and now everyone, Walter in particular, 
agree that it should be fixed[*].
But as for the other import features, I'm not sure the demand is that 
overwhelming. It's not the size of the thread that should judge that, 
there is lots of confusion(as Regan said) and also remnants of the 
original discussions. (Or maybe I'm just being "sly and blind"..)

[*] It is thanks to you kris, that of lack of FQN imports is now decided 
to be fixed. Despite I having mentioned this issue over a year ago, and 
also recently before this thread, you presented a hard and immediate 
example problem, which didn't occur to me or anyone else who 
participated in the previous discussions (the ones known of at least), 
and which convinced Walter to fix it.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 11 2006
parent reply Dave <Dave_member pathlink.com> writes:
Bruno Medeiros wrote:

 
 [*] It is thanks to you kris, that of lack of FQN imports is now decided 
 to be fixed. Despite I having mentioned this issue over a year ago, and 
 also recently before this thread, you presented a hard and immediate 
 example problem, which didn't occur to me or anyone else who 
 participated in the previous discussions (the ones known of at least), 
 and which convinced Walter to fix it.
 


Examples, hard evidence, *pragmatism* are the key to getting things 
changed. And it's the best standard IMO.

Walter is basing his resistance to syntax changes (i.e.: along the lines 
of from / as) because he hasn't yet seen much _D_ code that would 
greatly benefit from it. I submit that there is a good body of evidence 

because we all hope D libs. will soon emulate those in usefulness.
Jul 11 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Dave wrote:

 Bruno Medeiros wrote:

 [*] It is thanks to you kris, that of lack of FQN imports is now 
 decided to be fixed. Despite I having mentioned this issue over a year 
 ago, and also recently before this thread, you presented a hard and 
 immediate example problem, which didn't occur to me or anyone else who 
 participated in the previous discussions (the ones known of at least), 
 and which convinced Walter to fix it.


 
 Examples, hard evidence, *pragmatism* are the key to getting things 
 changed. And it's the best standard IMO.
 


I had a hard example too... but it required the existence of a 
code-completing IDE to be hard evidence >:P


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 11 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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.  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 :-)


 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.

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.


Sean
Jul 11 2006
next sibling parent Lucas Goss <lgoss007 gmail.com> writes:
Sean Kelly wrote:

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


Very well said. I think I see both points to the issue but sometimes an 
argument comes up that doesn't really address what the problem is and 
takes the topic off to discussing the same feature but a different issue 
(sometimes even the same issue with just a different syntax or style).

Kris and Walter both had some good points, and a summation from Walter 
of what he thinks should be done... BEFORE it's done would be nice.

Lucas
Jul 11 2006
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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!
Jul 11 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

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


I was quite surprised at the negative reaction to it from the people who 
suggested those changes.


 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.


I spent about 8 hours yesterday writing posts here. There's only so much 
I can do - especially since every post I write tends to generate a dozen 
responses.



 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.


I agree with waiting until things cool down.
Jul 12 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 12 Jul 2006 01:00:32 -0700, Walter Bright wrote:


 Sean Kelly wrote:

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




Yes Sean, I think you have raised good points there and I tend to agree
with them.


 I was quite surprised at the negative reaction to it from the people who 
 suggested those changes.


Just to clarify, not *all* people who suggested those changes that you
implemented were upset by you doing that. I use AAs a lot and I love the
changes you made to them. 


 I spent about 8 hours yesterday writing posts here. There's only so much 
 I can do - especially since every post I write tends to generate a dozen 
 responses.


But it has to be better listening to your valued clients and meeting their
needs than quietly, but surprisingly, implementing stuff that the clients
weren't interested in or in a manner that troubled them. Time invested in
reconnaissance is never wasted.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
12/07/2006 6:17:56 PM
Jul 12 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 On Wed, 12 Jul 2006 01:00:32 -0700, Walter Bright wrote:

 I was quite surprised at the negative reaction to it from the people who 
 suggested those changes.


 
 Just to clarify, not *all* people who suggested those changes that you
 implemented were upset by you doing that. I use AAs a lot and I love the
 changes you made to them. 


Thanks for letting me know that. It does make me feel better about that 
episode.
Jul 12 2006
parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 On Wed, 12 Jul 2006 01:00:32 -0700, Walter Bright wrote:

 I was quite surprised at the negative reaction to it from the people 
 who suggested those changes.


 Just to clarify, not *all* people who suggested those changes that you
 implemented were upset by you doing that. I use AAs a lot and I love the
 changes you made to them. 


 
 Thanks for letting me know that. It does make me feel better about that 
 episode.


I can't remember what I said at the time (if anything), but I think they 
work fine as well.
Jul 12 2006
prev sibling parent "John Reimer" <terminal.node gmail.com> writes:
On Wed, 12 Jul 2006 01:00:32 -0700, Walter Bright  
<newshound digitalmars.com> wrote:


 I spent about 8 hours yesterday writing posts here. There's only so much  
 I can do - especially since every post I write tends to generate a dozen  
 responses.



 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.


 I agree with waiting until things cool down.



Cool down, yes. "Not change a thing for reason X Y and Z", however, is NOT
a good alternative. I would find that very disturbing considering all the
energy put into this discussion.  That would leave the current problem with
name collisions a chronic problem for D, and many, many hours wasted for
everyone.

Much of the problem here too is that people started swamping this thread
(and other related threads) with numerous ideas for new import constructs.
We don't really need 100 new ideas for a construct at this stage... more so
we need (1) admission that a problem exists with the current import system
and (2) commitment to a fix.

(This whole process of swamping this newsgroup with alternative constructs
has very poor track record.  I'm not saying alternatives shouldn't be
discussed, but it's rather useless to do in this sort of system.  Walter is
incapable of investigating and studying every possibility.  He can barely
can keep up with posts here. Nor can I, for that matter.)

Walter suggested a fix that really didn't appear palatable to a vast
majority of the people here, and yet he remained unconvinced of any
alternatives, despite some very good ones being put forward.  Most of us
agreed that we would settle for something else, almost anything else that
Walter chose as long as it (1) met certain basic criteria (ie no explicit
use of alias, no use of "static import"), (2) was somewhat elegant, and (3)
fixed the original import problem.  That was our compromise, as hard as it
was (even at the expense of losing selective imports which people agreed  
was
useful but perhaps not critical).

So now we finish with a decision by dictatorship (I'm not being cute here;
just stating the facts) with the same mess of decision by committee... I
think we got nowhere just as fast: that everybody should cool down and
perhaps nothing at all should be done after all.  I'm not impressed.

Not to say a committee is any good, but this is no better, in my opinion,  
in
that the situation exchanges multi-level bureaucracy for single-level
stonewalling, sieged mightily by numerous community members that seem
tricked into thinking that their numerous suggestions will make a
difference, meanwhile vying with each other over numerous construct
alternatives (if you can follow that sentence, you win a prize; it's about
as clear as what's going on in this thread).  Even Walter can't (nor should
he be expected to) keep up to all the discussion which makes this all a
literal rats nest of useless brainstorming.

Walter, you said in another response to my post that, anybody could have
forked D at any time via gdc.  And the implication was that nobody has done
it because they trust in your leadership.  If that's what you meant, I  
don't
think that's necessarily the case, and it seems somewhat presumptuous of  
you
to think that way.  I'd say that people are reticent to do that sort of
thing out of respect for a your intellectual investment: it seems like a
harsh move and /could/ cast doubt on the original authors ability to manage
a language's design.  I really think the community wants to give you the
benefit of the doubt.  We have no desire to mess with what might be the
progress of D.  So see people's reticence to fork as a /desire/ to trust...
not trust it self.

But as time goes on, and more people get doubts about D's evolution, you
surely are tempting people to do consider forking.  Maybe a fork shouldn't
be looked at in such dark and sinister way.  Perhaps you don't mind?  
Perhaps
you would love to see an alternative that could share the research of a
alternative constructs such that trials could migrate back into the  
original
D?  I'm not sure if you would mind that or not.  If that's acceptable to
you, I guess it could be a useful alternative for testing out new  
principles
in D.  And I'd certainly hope that such an idea could be conducted with
cooperation and respect to you.

Cooling down is a great idea, but doing so does nothing to erase the issues
we have faced, currently face, and continue to face with the way D's growth
is managed.

-JJR
Jul 12 2006
prev sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:

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


You know, Walter, I'm more than willing to apologize profusely if you 
honestly feel you've been undeservedly slighted. And will do so 
earnestly and sincerely.

On the same token, there's little point in me denying that your approach 
here, as in previous similar discourse, is frustrating to the extreme; 
to the point where it often appears there's a notable lack of integrity, 
despite the presence of various other attributes which might otherwise 
be conducive to progress. Some will quietly agree with that, and some 
will disagree. Doesn't matter much.

What does matter (to me and probably to most of us) is the success of D 
in the one place where we can happily use it on a daily basis: where we 
get paid to use it. A small percentage of the D supporters go out of 
their way in order to help make that happen, Yet, you appear content to 
flatly dismiss a collective request for what seems to be a minor change.

Makes zero sense, and when my frustration with this aspect boils over 
then it's not exactly a big surprise to you or anyone else. You and I 
have a history of such exchanges, and that doesn't help either. However, 
it is more than thoroughly disappointing to see the community opinion 
dismissed in such a manner. Makes it harder to retain a level of faith 
in the genuine integrity of the overall situation; try as one might.

I'd like to gently suggest you place more value in those supporting D 
with their sustained efforts. Much more than zero. They are, after all, 
the very people who will be the most profound evangelists. That's not to 
say you should be swayed by individual opinion. Not at all. On the other 
hand, taking the position that you alone have the right answers while a 
significant group of experienced developers are united (with zero 
detractors!) in a request for a minor yet far-reaching positive change, 
is one that tends to shut the door on entirely the wrong people.

You've labeled this a "difference of opinion". If so, it would appear to 
be between you and a proactive, motivated, and valuable segment of the 
community.

Personally, I have to wonder what compelling reason there is to continue 
ploughing so much effort into helping make D a success, behind the 
scenes, when it appears to have so little value in your eyes. I'm far 
from being the first to feel this way, and probably won't be the last. 
Naturally one can hardly expect you to be able to provide such a reason, 
but I will urge you again to place some merit in the experience and 
knowledge of this group. As individuals, none of us are infallible.
Jul 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 Personally, I have to wonder what compelling reason there is to continue 
 ploughing so much effort into helping make D a success, behind the 
 scenes, when it appears to have so little value in your eyes.


Language design is hardly cut and dried. There is rarely a right and a 
wrong answer. There are only benefits and costs, and those vary from 
application to application, and peoples' opinions of them vary as well.

You and I have different opinions about how certain things should work. 
Nothing more should be read into it than that.
Jul 12 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:


 kris wrote:

 Personally, I have to wonder what compelling reason there is to continue
 ploughing so much effort into helping make D a success, behind the
 scenes, when it appears to have so little value in your eyes.


 
 Language design is hardly cut and dried. There is rarely a right and a
 wrong answer. There are only benefits and costs, and those vary from
 application to application, and peoples' opinions of them vary as well.
 
 You and I have different opinions about how certain things should work.
 Nothing more should be read into it than that.


But you would have to agree with the fact that on this matter and quite a
few others, more people tend to agree with Kris rather than you?

I am very happy that you seem to go for "private by default", but if you
don't actually give us a real solution to the symbol collision mess
(without using those static or alias), we are after all seeing a rare
agreement in this NG that your proposed solution is more or less worse than
what we already have, I suspect the discussions will flare again with even
more intensity. Cooling down the discussion don't mean that we should
implement a bad solution. Private imports by default are just minor
nitpicks compared to the namespace collision problems.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 12 2006
prev sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:
 

 Personally, I have to wonder what compelling reason there is to 
 continue ploughing so much effort into helping make D a success, 
 behind the scenes, when it appears to have so little value in your eyes.


 
 
 Language design is hardly cut and dried. There is rarely a right and a 
 wrong answer. There are only benefits and costs, and those vary from 
 application to application, and peoples' opinions of them vary as well.
 
 You and I have different opinions about how certain things should work. 
 Nothing more should be read into it than that.



Excuse me ... you and the *community* have different opinions !

Do yourself, and everyone here, a big favour and stop insisting this 
this is between you and I. By doing so, you send a clear message that 
the opinions of everyone else clamouring (or begging) for exactly the 
same thing is utterly worthless. That the community segment requesting 
this small change simply don't know what they are talking about. Fools 
that we all are.

The attitude here is exactly what was alluded to in the original post; 
you make a point of utterly ignoring (and removing) the principal 
points, and contort what little is left. Frankly, such behaviour should 
not be tolerated within this community.

To make it perfectly clear, yet again, we're *all* asking for the 
equivalent of a combined import and alias:

import x.y.z as n;

where n becomes a required prefix. We're not interested in using alias 
as a secondary instruction, for all the myriad reasons noted that you 
have yet to even acknowledge exist. And the "static import", as you've 
surely seen by the many negative responses, simply does not cut the 
mustard with the D community.

I'm reattaching the original post, Since the essence there has been lost:






Walter Bright wrote:


 kris wrote:


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


You know, Walter, I'm more than willing to apologize profusely if you 
honestly feel you've been undeservedly slighted. And will do so 
earnestly and sincerely.

On the same token, there's little point in me denying that your approach 
here, as in previous similar discourse, is frustrating to the extreme; 
to the point where it often appears there's a notable lack of integrity, 
despite the presence of various other attributes which might otherwise 
be conducive to progress. Some will quietly agree with that, and some 
will disagree. Doesn't matter much.

What does matter (to me and probably to most of us) is the success of D 
in the one place where we can happily use it on a daily basis: where we 
get paid to use it. A small percentage of the D supporters go out of 
their way in order to help make that happen, Yet, you appear content to 
flatly dismiss a collective request for what seems to be a minor change.

Makes zero sense, and when my frustration with this aspect boils over 
then it's not exactly a big surprise to you or anyone else. You and I 
have a history of such exchanges, and that doesn't help either. However, 
it is more than thoroughly disappointing to see the community opinion 
dismissed in such a manner. Makes it harder to retain a level of faith 
in the genuine integrity of the overall situation; try as one might.

I'd like to gently suggest you place more value in those supporting D 
with their sustained efforts. Much more than zero. They are, after all, 
the very people who will be the most profound evangelists. That's not to 
say you should be swayed by individual opinion. Not at all. On the other 
hand, taking the position that you alone have the right answers while a 
significant group of experienced developers are united (with zero 
detractors!) in a request for a minor yet far-reaching positive change, 
is one that tends to shut the door on entirely the wrong people.

You've labeled this a "difference of opinion". If so, it would appear to 
be between you and a proactive, motivated, and valuable segment of the 
community.

Personally, I have to wonder what compelling reason there is to continue 
ploughing so much effort into helping make D a success, behind the 
scenes, when it appears to have so little value in your eyes. I'm far 
from being the first to feel this way, and probably won't be the last. 
Naturally one can hardly expect you to be able to provide such a reason, 
but I will urge you again to place some merit in the experience and 
knowledge of this group. As individuals, none of us are infallible.
Jul 12 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Wed, 12 Jul 2006 15:58:56 -0400, kris <foo bar.com> wrote:


 Walter Bright wrote:

 kris wrote:


 Personally, I have to wonder what compelling reason there is to  
 continue ploughing so much effort into helping make D a success,  
 behind the scenes, when it appears to have so little value in your  
 eyes.


   Language design is hardly cut and dried. There is rarely a right and  
 a wrong answer. There are only benefits and costs, and those vary from  
 application to application, and peoples' opinions of them vary as well.
  You and I have different opinions about how certain things should  
 work. Nothing more should be read into it than that.



 Excuse me ... you and the *community* have different opinions !

 Do yourself, and everyone here, a big favour and stop insisting this  
 this is between you and I. By doing so, you send a clear message that  
 the opinions of everyone else clamouring (or begging) for exactly the  
 same thing is utterly worthless. That the community segment requesting  
 this small change simply don't know what they are talking about. Fools  
 that we all are.

 The attitude here is exactly what was alluded to in the original post;  
 you make a point of utterly ignoring (and removing) the principal  
 points, and contort what little is left. Frankly, such behaviour should  
 not be tolerated within this community.

 To make it perfectly clear, yet again, we're *all* asking for the  
 equivalent of a combined import and alias:

 import x.y.z as n;

 where n becomes a required prefix. We're not interested in using alias  
 as a secondary instruction, for all the myriad reasons noted that you  
 have yet to even acknowledge exist. And the "static import", as you've  
 surely seen by the many negative responses, simply does not cut the  
 mustard with the D community.


I'm not against devising new syntax for this, just thought I'd explore  
current means first.

I thought it would be fine just importing inside a struct like so:  struct  
n { import x.y.z; }  to achieve the same thing, but it turns out, this  
style importing is frowned upon and can cause major issues. Perhaps it's a  
bug that should be resolved? or something that should be forbidden?

But with a new syntax, I suspect it'd be best to not even use "as" or  
another word or operator and just use  import x.y.z n;  just like a  
regular declaration or mixin identifier doesn't need it:  int as n;  mixin  
foo as bar;
Jul 12 2006
parent Walter Bright <newshound digitalmars.com> writes:
Chris Miller wrote:

 I thought it would be fine just importing inside a struct like so:  
 struct n { import x.y.z; }  to achieve the same thing, but it turns out, 
 this style importing is frowned upon and can cause major issues. Perhaps 
 it's a bug that should be resolved? or something that should be forbidden?


There were bugs with it, but were resolved. It's there because:

1) the language should be as consistent as possible. C++ is loaded up 
with weird special case rules that serve to make the language very hard 
to master.

2) features can often be combined in unexpected and fruitful ways; we 
should be careful to not close the door on that unless absolutely necessary.
Jul 12 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 Walter Bright wrote:

 kris wrote:

 Personally, I have to wonder what compelling reason there is to 
 continue ploughing so much effort into helping make D a success, 
 behind the scenes, when it appears to have so little value in your eyes.


 You and I have different opinions about how certain things should 
 work. Nothing more should be read into it than that.


 Excuse me ... you and the *community* have different opinions !
 
 Do yourself, and everyone here, a big favour and stop insisting this 
 this is between you and I.


What I am referring to is your inference of nefarious motives when I 
disagree with you.
Jul 12 2006
parent kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:
 

 Walter Bright wrote:


 kris wrote:


 Personally, I have to wonder what compelling reason there is to 
 continue ploughing so much effort into helping make D a success, 
 behind the scenes, when it appears to have so little value in your 
 eyes.


 You and I have different opinions about how certain things should 
 work. Nothing more should be read into it than that.


 Excuse me ... you and the *community* have different opinions !

 Do yourself, and everyone here, a big favour and stop insisting this 
 this is between you and I.


 
 
 What I am referring to is your inference of nefarious motives when I 
 disagree with you.



This whole thing has become far more complex than it need be. The 
community is asking for what seems to be a minor syntactic change, to 
provide notable positive value. You feel such changes are entirely 
unecessary, that the value is simply not there, and place little no 
value in the highly-visible community desire, experience, and knowledge.

At the same time, you claim "D goes where the community wants it to". 
Yet, what further evidence is needed to show that the commmunity desires 
an "import x.y.z as n;" or "import x.y.z : n;" or import "import x.y.z n"?

1) Perfectly adequate reasons have been offered forth by various parties.
2) The community is united in asking for "something better". This is a 
true rarity in and of itself.
3) It does not affect existing code at all.
4) It appears to be reasonably straightforward to implement (if static 
import is not difficult, then the extension to the desired approach 
should not be notably more so)
5) it fixes the ancient namespace-collision problem, and is effortless 
enough to /encourage/ the use of safer imports. What could be better?

Just what more is needed, exactly? What more does it take for an 
unobtrusive change to be effected? Exactly what does the 'motto' mean, 
if all the above is still not sufficient to garner such a non-impact 
change?





 What I am referring to is your inference of nefarious motives when I 
 disagree with you.


Au contraire; learned friend.

If there are indeed nefarious motivation, it is evidenced within your 
replies to various posts. I contend that posts by others are exhibiting 
a similar level of frustration for similar reason, and, whatever you 
refer to is not reserved for me alone. Thus, it cannot be simply when 
you and I disagree.
Jul 12 2006
prev sibling next sibling parent Bill Baxter <Bill_member pathlink.com> writes:
In article <e8usq9$30df$1 digitaldaemon.com>, Walter Bright says...

Dave wrote:

 I'm not sure what exactly Kris said, but imports are ubiquitous.
 Not used as much as loops of course, but they are used in every program.


Yes, they are ubiquitous. But the renaming of imported symbols? I'm not 
convinced that is at all ubiquitous, or that it is very desirable in any 
but unusual cases.


Renaming imported symbols is pretty common in Python, I think.
from numpy import transpose as T
was one I used myself recently.

Renaming namespaces in python is quite common too.  A lot of numpy users seem to
always start with this:
import numpy as N

Also I seem to be seeing it more in recent C++ programs (aliasing the whole
namespace, anyway, which is all C++ gives you) -- 
namespace NCF = a_really_long_namespace_called_foo


Also note that the current D import behavior corresponds to this in Python:
from some_module import *
which is something they say you should "avoid whenever *reasonably* possible".

--Bill
Jul 10 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Dave wrote:

 I'm not sure what exactly Kris said, but imports are ubiquitous.


  > Not used as much as loops of course, but they are used in every 


program.

 Yes, they are ubiquitous. But the renaming of imported symbols? I'm 


not convinced that is at all ubiquitous, or that it is very desirable in 
any but unusual cases.

Because when libs. and the projects that use them get bigger it will 
probably get much more desirable, and not for just unusual cases.


the 'using' directive can abandon the FQN:

System.Data.OleDb.OleDbCommand cmd = new 
System.Data.OleDb.OleDbCommand(...);

or

using System.Data.OleDb;
...
OleDbCommand cmd = new OleDbCommand(...);

and then:

using olecmd = System.Data.OleDb.OleDbCommand;
using odbcmd = System.Data.Odbc.OdbcCommand;
...
olecmd ocmd = new olecmd();
...
odbcmd dcmd = new odbcmd();

the last form is like the from / as syntax.

I like it - it can *really* cut down on the amount of superfluous code 
you have to write / scan / read for things like OleDbCommand, which are 


Because of the size of the .NET library, namespaces like 
'System.Data.OleDb' (or worse) are very uncommon.


  > 2) how much power it adds

 It adds the ability to import specific symbols - a quite powerful 




addition to import I think.

 But that power already exists. The discussion is now about whether 


two statements should be combined into one or not. The power is the same.

Yes but the proposed syntax also allows things like this:

import from a.very.popular.db.lib open as dbopen, close as dbclose;

rather than

import a.very.popular.db.lib;
alias a.very.popular.db.lib dblib;
alias dblib.open dbopen;
alias dblib.close dbclose;

Actually I think there is another criteria: 7) Does a feature build-in 
something useful or more convenient for large scale development that C 


The 'from' / 'as' syntax does that as well, again IMHO.

Walter, only you know how tough it is to implement. If it would be a 
total PITA to implement over 'static import' than I completely 
understand, especially at this stage.

- Dave
Jul 10 2006
prev sibling next sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 David Medlock wrote:
 

 Derek Parnell wrote:


 I'm hope I'm not messing up Kris' words here but I think he is saying 
 that  we need to cut down on the amount of typing and reading people 
 *must* do  in a program. Keep it to a minimum. Try and work the 
 syntax so that the  common and mandatory things are short, easy, and 
 intuitive to do. Make the  unusual and 'special' things have more 
 detail in the syntax.


 I 100% agree.  The usual cases should be implicit, and the corner 
 cases explicit.


 
 
 But *are* they the usual case? As far as I can tell, Python is the only 
 significant language that allows aliasing of import names (though the 
 Python manual calls it "binding"). (We'll set aside the C++ #define 
 trick as not a reasonable method.) I haven't seen it used in Python 
 code, though I admit I haven't seen much Python code.
 
 That's why I suggest just trying it for a while. Kris' original concerns 
 are met with the combination of 'static import' (I know, I know, should 
 think of some better keyword combination) and 'alias'. Syntax changes 
 should be done conservatively - if there's an existing way to do it, it 
 has to be used a lot to justify special syntax for it.


Yes, most of us are sensitive to that also. But it needs to be traded 
off carefully against usage patterns. I suggest you take a look at 
Sean's extensive and carefully considered reponse from yesterday, and 
perhaps mine also, since you appear to have ignored everything stated in 
both judging by the above comment?

BTW: it's perfectly feasible to handle all requirements with no new 
keywords at all:

import lib.text.locale;

import lib.text.locale : locale;

import lib.text.locale.Date;

import lib.text.locale.Date : myDate;



 Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, but 
 loops are so very, very common that special syntactic sugar for it has 
 proven to be a big win.


This comes across as thoroughly disingeneous. If you want a comparison, 
Walter, use your own comparison with the built-in regex?

As was pointed out, Regex is /very/ rarely used in the grand scheme of 
things. Whereas import is used multiple times in pretty much every 
single module. It would be a mildly positive sign if you'd at least 
acknowledge that fact?

I again implore you to revisit those posts, and the followup ones posted 
by Dave and the many others.



 D already has a lot of syntax in it. We should be very careful about 
 adding more; not every convenience should have its own syntactic sugar.



Recall the following:

1) the concept of modules and the usage thereof is considered a 
principal aspect of D, and

2) import is something used *several times* in pretty much every D module

Thus, the earlier question remains: Do you, or do you not, wish the safe 
approach for import to be easy and convenient to use, maintain, and 
understand at a glance?
Jul 10 2006
parent Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 BTW: it's perfectly feasible to handle all requirements with no new 
 keywords at all:
 
 import lib.text.locale;
 
 import lib.text.locale : locale;
 
 import lib.text.locale.Date;
 
 import lib.text.locale.Date : myDate;


I know. The ':' isn't even necessary.


 Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, 
 but loops are so very, very common that special syntactic sugar for it 
 has proven to be a big win.


 This comes across as thoroughly disingeneous. If you want a comparison, 
 Walter, use your own comparison with the built-in regex?
 As was pointed out, Regex is /very/ rarely used in the grand scheme of 
 things. Whereas import is used multiple times in pretty much every 
 single module. It would be a mildly positive sign if you'd at least 
 acknowledge that fact?


The idea with regex came from Matthew's comments that when he wanted to 
do regex, he went with Ruby. Ruby and Perl have regex front and center, 
and they are heavily used in those languages. So, the fact that they are 
lightly used in D may be caused by them being *difficult to use* in D 
rather than because there is no interest in regex.

So I wanted to see why regex was so convenient in Ruby, and if that 
convenience could be migrated to D, thereby making D suitable for 
applications that did make heavy use of regex. Sort of "build it and see 
if they come", if you may.

Import is used everywhere. No argument there. But is selective import? 
Import with renaming? That is far less clear. If the latter capabilities 
are critical and would be ubiquitously used, why aren't they in C, C++, 

Python?

(On a personal style note, I wouldn't want to rename imports, especially 
if a lot of programmers are working on the project. I'd rather use FQN's 
so when I see foo.bar.abc, I know we're talking about the same thing.)

And I want to add once again, that we are not talking about a difference 
in power or capability. Just whether it is two statements, one of which 
uses existing D capabilities, or a sprinkle of syntactic sugar to 
combine them into one statement.

And lastly, to reiterate, it is not about how often import is used. It 
is how often selective import, or import with renaming, is likely to be 
used.
Jul 10 2006
prev sibling next sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <e8u8ed$1vsl$1 digitaldaemon.com>, Walter Bright says...

David Medlock wrote:

 Derek Parnell wrote:
 

 I'm hope I'm not messing up Kris' words here but I think he is saying 
 that  we need to cut down on the amount of typing and reading people 
 *must* do  in a program. Keep it to a minimum. Try and work the syntax 
 so that the  common and mandatory things are short, easy, and 
 intuitive to do. Make the  unusual and 'special' things have more 
 detail in the syntax.


 
 I 100% agree.  The usual cases should be implicit, and the corner cases 
 explicit.


But *are* they the usual case? As far as I can tell, Python is the only 
significant language that allows aliasing of import names (though the 
Python manual calls it "binding"). (We'll set aside the C++ #define 
trick as not a reasonable method.) I haven't seen it used in Python 
code, though I admit I haven't seen much Python code.

That's why I suggest just trying it for a while. Kris' original concerns 
are met with the combination of 'static import' (I know, I know, should 
think of some better keyword combination) and 'alias'. Syntax changes 
should be done conservatively - if there's an existing way to do it, it 
has to be used a lot to justify special syntax for it.


Walter, we've gone over this several times.  I guess we should keep repeating
ourselves?  "static import" is a weak solution; it's verbose and lacking in
clarity.  If people are to learn D, I think that will be a particularly volatile
area: it needs to be represented in as clear a syntax as possible, especially
since the import/module system will be among the first systems learned by the
new D programmer.  You are clearly a biased party if you think that static
import is an easily understood solution to the problem, and therefore, you
shouldn't be so heavily involved in the decision. ;)

While we understand your desire to keep syntax additions down, there are
situations where being conservative isn't an answer.  If you can find something
equivalent to from/as (which you most certainly haven't), without adopting new
syntax, maybe we'll bite... but so far, I think using 'with' (or from) and 'as'
is an excellent contender.  And no, I don't think we're overburdening D with
this new syntax, since this is such a critical issue.


Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, but 
loops are so very, very common that special syntactic sugar for it has 
proven to be a big win.



I think you are missing the point. *sigh*. Read above. Imports/namespaces make
up what constitutes a D program.  I think it's a very central, critical, and
special to D.



D already has a lot of syntax in it. We should be very careful about 
adding more; not every convenience should have its own syntactic sugar.


There are absolutely no worries about being careful, Walter... You've been
extremely careful. Really!  This syntactic sugar, as you call it, cuts down an
whole lot of lines of code in an area and, at the same time, clarifies the whole
action of the namespace domain.  This is no mere syntactic sugar.  Furthermore,
the term "syntactic sugar" is getting rediculously overused lately... what is
syntactic sugar?  What makes something syntactic sugar?  Who decides what is
syntactic sugar?  That's what high level langauges are, in fact: syntactic
sugar.  

What we're talking about is keeping constructs logical, consistant and minimal:
understood.  But that is the whole point of langauge design, is it not? It's too
decide when and where syntactic sugar is appropriate. 

Imports is such a time to make that consideration.

-JJR
Jul 10 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:

 If you can find something
 equivalent to from/as (which you most certainly haven't), without adopting new
 syntax, maybe we'll bite... but so far, I think using 'with' (or from) and 'as'
 is an excellent contender.


I'll repeat myself here, too <g>. The 'static import' combined with 
'alias' has

	*exactly the same semantics*

as 'with' 'as'. The only difference between the proposals is if there 
are two statements or one. There is no difference in power or effect. 
There is nothing that one can do that the other cannot.



 I think you are missing the point. *sigh*. Read above. Imports/namespaces make
 up what constitutes a D program.  I think it's a very central, critical, and
 special to D.


I certainly agree with that. What I am unconvinced of, however, is that 

etc., do not support renaming. Only Python seems to. And only D has a 
general purpose renaming capability.
Jul 10 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 I certainly agree with that. What I am unconvinced of, however, is that 

 etc., do not support renaming. Only Python seems to. And only D has a 
 general purpose renaming capability.


It's a valid point.  However, C++ supports namespaces and 'using' as a 
means of arbitrarily manipulating scope signifiers and providing short 
prefixes if the supplied one is too long (though it typically isn't, 
since C++ does not have a 1-1 mapping between file name/location and 
FQN).  And C is simply too antiquated/low-level to consider.  I'm not 

suppose anyone with more experience could comment?


Sean
Jul 10 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 I certainly agree with that. What I am unconvinced of, however, is 
 that the *renaming* is central or critical. Note that C, C++, Java, 

 only D has a general purpose renaming capability.


 
 It's a valid point.  However, C++ supports namespaces and 'using' as a 
 means of arbitrarily manipulating scope signifiers and providing short 
 prefixes if the supplied one is too long (though it typically isn't, 
 since C++ does not have a 1-1 mapping between file name/location and 
 FQN).  And C is simply too antiquated/low-level to consider.  I'm not 

 suppose anyone with more experience could comment?


A correction to my post: C++ does have namespace-alias-definitions, 
where a namespace name can be aliased.
Jul 10 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Sean Kelly wrote:

 ...
 FQN).  And C is simply too antiquated/low-level to consider.  I'm not 

 suppose anyone with more experience could comment?
 
 Sean



it into the local namespace. If there is a collision you have to use the 
FQN.

Lucas
Jul 11 2006
parent reply Dave <Dave_member pathlink.com> writes:
Lucas Goss wrote:

 Sean Kelly wrote:

 ...
 FQN).  And C is simply too antiquated/low-level to consider.  I'm not 

 suppose anyone with more experience could comment?

 Sean


 

 it into the local namespace. If there is a collision you have to use the 
 FQN.
 
 Lucas


There also the 'using x = [namespace|symbol];' form, which allows you to 
assign a namespace _or_ a specific symbol a different name.

See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/40005

I think they by and large got it right.


of code to type / scan / read explodes because of the long namespace 
names in the .NET lib.
Jul 11 2006
parent Lucas Goss <lgoss007 gmail.com> writes:
Dave wrote:

 
 There also the 'using x = [namespace|symbol];' form, which allows you to 
 assign a namespace _or_ a specific symbol a different name.
 
 See: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/40005
 


Ah, I had read that post after I posted.


 I think they by and large got it right.
 






 of code to type / scan / read explodes because of the long namespace 
 names in the .NET lib.


I've seen a few FQN's, but yes they are very rare.

Lucas
Jul 11 2006
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:

 John Reimer wrote:

 If you can find something
 equivalent to from/as (which you most certainly haven't), without 
 adopting new
 syntax, maybe we'll bite... but so far, I think using 'with' (or from) 
 and 'as'
 is an excellent contender.


 
 I'll repeat myself here, too <g>. The 'static import' combined with 
 'alias' has
 
     *exactly the same semantics*
 
 as 'with' 'as'. The only difference between the proposals is if there 
 are two statements or one. There is no difference in power or effect. 
 There is nothing that one can do that the other cannot.



Not true. With the static import + alias you'll have two different ways 
to refer to the imported symbol(s), and no restriction as to which one 
is used.

With "as"/"from"/":"/whatever you'll have only 1 way. If you see 
"bar.foo", there's only 1 thing it can mean.

(With the current import + alias you'll have *3* names for the same 
thing. I've read somewhere that this is something people generally have 
problems with, some psychology thing.)

L.
Jul 10 2006
parent Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 Walter Bright wrote:

 John Reimer wrote:

 If you can find something
 equivalent to from/as (which you most certainly haven't), without 
 adopting new
 syntax, maybe we'll bite... but so far, I think using 'with' (or 
 from) and 'as'
 is an excellent contender.


 I'll repeat myself here, too <g>. The 'static import' combined with 
 'alias' has

     *exactly the same semantics*

 as 'with' 'as'. The only difference between the proposals is if there 
 are two statements or one. There is no difference in power or effect. 
 There is nothing that one can do that the other cannot.


 
 
 Not true. With the static import + alias you'll have two different ways 
 to refer to the imported symbol(s), and no restriction as to which one 
 is used.


True, but I thought that was unimportant. It's not that you're likely to 
type in very.long.qualified.name by accident.


 With "as"/"from"/":"/whatever you'll have only 1 way.


Not necessarily. Read on...


 If you see "bar.foo", there's only 1 thing it can mean.


That's true regardless of whether there exists a different path to the 
symbol or not.

Like directory names in a filesystem, there can be an arbitrarily large 
number of paths to reference symbols at module scope:

--- module A ---
import module B;

--- module B ---
void foo();

--- module C ---
import A;
import B;

B.foo();
A.B.foo();
Jul 11 2006
prev sibling next sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e8utvp$53$1 digitaldaemon.com...

 John Reimer wrote:

 If you can find something
 equivalent to from/as (which you most certainly haven't), without 
 adopting new
 syntax, maybe we'll bite... but so far, I think using 'with' (or from) 
 and 'as'
 is an excellent contender.


 I'll repeat myself here, too <g>. The 'static import' combined with 
 'alias' has

 *exactly the same semantics*

 as 'with' 'as'. The only difference between the proposals is if there are 
 two statements or one. There is no difference in power or effect. There is 
 nothing that one can do that the other cannot.



The semantics are not exactly the same.  Read Sean and Kris's explanations 
again, please.  'static import' adds nothing to the what this whole 
namespace business.  It just sharpens the compiler a bit to enforce FQN for 
the programmer's sake.  But that is absolutely unnecessary because a D 
programmer that wants to do that now can just make sure he uses FQNs!  So 
what's the point of 'static import'?

Also see Lionello Lunesu's post in response to you.



 I think you are missing the point. *sigh*. Read above. Imports/namespaces 
 make
 up what constitutes a D program.  I think it's a very central, critical, 
 and
 special to D.


 I certainly agree with that. What I am unconvinced of, however, is that 

 etc., do not support renaming. Only Python seems to. And only D has a 
 general purpose renaming capability.



I get that you are unconvinced.  In fact, I think it's more than quite 

2, or Simula. Neither is it Python. In fact, D is D.  And we're the D 
community.  If you want to keep trying to sell D to the C++ community, 
you've already failed.  The majority of that group will never be convinced 
as long as they are having their love affair with C++ or are wistfully 
forseeing an upcoming C++ standard with all the "incredible" features they 
ever wanted.  Many people choose to be blind because it means inconvenience 
and turmoil otherwise to see what might be a good for them.

But, for your sake, I hope you realize the community here is your best 
investment.  Improve D with a conscience for good design, but please stop 
being ( what appears to be ) double minded about who you are trying to 
appeal to. Forget the C++ people.  Think of D with wild abandon and commit 
to making it a true replacement, a bonifide departure from C++.  Yes, 
absolutely maintain that eye for proven methods, but please don't let that 
limit your sights if such things don't appear to have been "verified" . No 
new inventions can succeed while it waits for others to complete the process 
of collecting the scientific data, of proving it.

What we have asked for here is hardly such a complicated feature that you 
should be worrying on that level.  It's been demonstrated carefully and 
methodically how it simplifies the D programmer's life.  Many people, the 
majority I think, have been supportive of it.  Yet you still appeal to the 
example of other languages, some that were designed for different audiences.

Finally, the only ones that are interested in learning D are the ones that 
are fed up with the ugliness and complexity of C++ to such an extent that 
they decide to see what D is about.  D can certainly start exploring some 
new territory to prove that there are ways to do things better (and so you 
have done!).  C++ can never approach that angle because whatever it adds to 
fix the problems it has, will only make it more complex.

-JJR
Jul 11 2006
parent reply Don Clugston <dac nospam.com.au> writes:
John Reimer wrote:

 
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e8utvp$53$1 digitaldaemon.com...

 John Reimer wrote:

 If you can find something
 equivalent to from/as (which you most certainly haven't), without 
 adopting new
 syntax, maybe we'll bite... but so far, I think using 'with' (or 
 from) and 'as'
 is an excellent contender.


 I'll repeat myself here, too <g>. The 'static import' combined with 
 'alias' has

 *exactly the same semantics*

 as 'with' 'as'. The only difference between the proposals is if there 
 are two statements or one. There is no difference in power or effect. 
 There is nothing that one can do that the other cannot.


 
 
 The semantics are not exactly the same.  Read Sean and Kris's 
 explanations again, please.  'static import' adds nothing to the what 
 this whole namespace business.  It just sharpens the compiler a bit to 
 enforce FQN for the programmer's sake.  But that is absolutely 
 unnecessary because a D programmer that wants to do that now can just 
 make sure he uses FQNs!  So what's the point of 'static import'?


I have to disagree with this. Currently, suppose you have a module that 
uses the toString() functions from std.string (and uses them hundreds of 
times). Then, you decide you need to use std.date in one place to get 
the current time. Suddenly, your module won't compile, because 
std.date.toString() conflicts with all the other toString()s that you're 
using. Even though you're not even using std.date.toString !

With the static import proposal, you could just have

import std.string;
static import std.date;

and then use FQNs for the single usage of date.

This is not a contrived example, I encountered it in my second D program 
(and I immediately thought that there were serious problems with the D 
module system. You're telling me I have to alias std.string.toString 
just because I want to use std.date.getUTCtime() ???). 'static import' 
would make it possible to avoid the use of FQNs in most cases; it would 
enable you to distinguish 'I'm going to use a function from this module' 
(static import) from 'I'm heavily depending on this module' (normal import).

Which is not to say that I'm favouring 'static import' in this 
discussion, I'm simply saying that all of the proposals, including 
static import, are an *enormous* improvement over what we have now.
Jul 11 2006
next sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e8utvp$53$1 digitaldaemon.com...

 John Reimer wrote:

 If you can find something
 equivalent to from/as (which you most certainly haven't), without 
 adopting new
 syntax, maybe we'll bite... but so far, I think using 'with' (or from) 
 and 'as'
 is an excellent contender.


 I'll repeat myself here, too <g>. The 'static import' combined with 
 'alias' has

 *exactly the same semantics*

 as 'with' 'as'. The only difference between the proposals is if there 
 are two statements or one. There is no difference in power or effect. 
 There is nothing that one can do that the other cannot.



 The semantics are not exactly the same.  Read Sean and Kris's 
 explanations again, please.  'static import' adds nothing to the what 
 this whole namespace business.  It just sharpens the compiler a bit to 
 enforce FQN for the programmer's sake.  But that is absolutely 
 unnecessary because a D programmer that wants to do that now can just 
 make sure he uses FQNs!  So what's the point of 'static import'?


 I have to disagree with this. Currently, suppose you have a module that 
 uses the toString() functions from std.string (and uses them hundreds of 
 times). Then, you decide you need to use std.date in one place to get the 
 current time. Suddenly, your module won't compile, because 
 std.date.toString() conflicts with all the other toString()s that you're 
 using. Even though you're not even using std.date.toString !


Fair enough.

I've seen this error also on several occasions.  I can't remember the exact 
source of it, but I think it's related to another issue.  It was my 
understanding that that was due to public imports somewhere up the line. 
This might have been one of the reasons why discussions started concerning a 
borked import system.  Perhaps I'm wrong?

There used to be confusion relating to D's name lookup mechanism. Importing 
a module into a class declaration was a huge mess, because people didn't 
realize how name lookup worked in D.



 With the static import proposal, you could just have

 import std.string;
 static import std.date;

 and then use FQNs for the single usage of date.



Er.. that tells me more that there's a problem with the original mechanism. 
And "static import" is a workaround.  Why not fix the original import 
system?  There must be something wrong with it.  So are we adding new 
constructs to workaround name clashes? Is that a good idea?  Is that the 
reason 'static import' was suggested?  There shouldn't be name clashes when 
fully qualified names are used in the first place! If there are, that's an 
unrelated problem and should be addressed and fixed, apart from this whole 
thread before we proceed.



 This is not a contrived example, I encountered it in my second D program 
 (and I immediately thought that there were serious problems with the D 
 module system. You're telling me I have to alias std.string.toString just 
 because I want to use std.date.getUTCtime() ???). 'static import' would 
 make it possible to avoid the use of FQNs in most cases; it would enable 
 you to distinguish 'I'm going to use a function from this module' (static 
 import) from 'I'm heavily depending on this module' (normal import).



I say 'static import' is a cheap fix for a major problem in the import 
system, then. :P



 Which is not to say that I'm favouring 'static import' in this discussion, 
 I'm simply saying that all of the proposals, including static import, are 
 an *enormous* improvement over what we have now.



I understand. But I still think that using 'static import' as a fix is not 
the solution.

-JJR
what we have now.
Jul 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:

 I've seen this error also on several occasions.  I can't remember the 
 exact source of it, but I think it's related to another issue.  It was 
 my understanding that that was due to public imports somewhere up the 
 line. This might have been one of the reasons why discussions started 
 concerning a borked import system.  Perhaps I'm wrong?


How imports work is that first a name is searched for in the current 
namespace. If it is not found, then it is looked for in the import list. 
If it is found uniquely among the imports, then that is used. If it is 
in more than one import, an error occurs:

--- module A ---
void foo();
void bar();

--- module B ---
void foo();
void bar();

--- module C ---
import A;
void foo();
void test()
{ foo(); // C.foo() is called, it is found before imports are searched
   bar(); // A.bar() is called, since imports are searched
}

--- module D ---
import A;
import B;
void test()
{ foo();   // error, A.foo() or B.foo() ?
   A.foo(); // ok, call A.foo()
   B.foo(); // ok, call B.foo()
}

--- module E ---
import A;
import B;
alias B.foo foo;
void test()
{ foo();   // call B.foo()
   A.foo(); // call A.foo()
   B.foo(); // call B.foo()
}

And that's all there is to it. If you always used FQNs, you'll never run 
into any collision or ambiguity issues.


 Er.. that tells me more that there's a problem with the original 
 mechanism. And "static import" is a workaround.  Why not fix the 
 original import system?  There must be something wrong with it.  So are 
 we adding new constructs to workaround name clashes? Is that a good 
 idea?  Is that the reason 'static import' was suggested?  There 
 shouldn't be name clashes when fully qualified names are used in the 
 first place!


There aren't any name clashes if you use FQN's.



 Which is not to say that I'm favouring 'static import' in this 
 discussion, I'm simply saying that all of the proposals, including 
 static import, are an *enormous* improvement over what we have now.




All 'static import' does is eliminate the "if the name is not found in 
the current module, look in the imports" step. This has the effect of 
requiring the use of FQN's when referencing imports.

Then in steps alias, which can be used to selectively bind import 
symbols into the current module namespace.
Jul 11 2006
parent reply David Medlock <noone nowhere.com> writes:
Walter Bright wrote:

 John Reimer wrote:
 

 I've seen this error also on several occasions.  I can't remember the 
 exact source of it, but I think it's related to another issue.  It was 
 my understanding that that was due to public imports somewhere up the 
 line. This might have been one of the reasons why discussions started 
 concerning a borked import system.  Perhaps I'm wrong?


 
 
 How imports work is that first a name is searched for in the current 
 namespace. If it is not found, then it is looked for in the import list. 
 If it is found uniquely among the imports, then that is used. If it is 
 in more than one import, an error occurs:


That is not how aliases currently work, just a friendly reminder.
-DavidM
Jul 11 2006
parent Walter Bright <newshound digitalmars.com> writes:
David Medlock wrote:

 Walter Bright wrote:

 How imports work is that first a name is searched for in the current 
 namespace. If it is not found, then it is looked for in the import 
 list. If it is found uniquely among the imports, then that is used. If 
 it is in more than one import, an error occurs:


 
 That is not how aliases currently work, just a friendly reminder.


True, because that's how imports work, not aliases. But I'm not sure 
what's on your mind with that statement?
Jul 12 2006
prev sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
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


"Don Clugston" <dac nospam.com.au> wrote in message 
news:e8vn6d$1bm0$1 digitaldaemon.com...

 John Reimer wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e8utvp$53$1 digitaldaemon.com...

 John Reimer wrote:

 If you can find something
 equivalent to from/as (which you most certainly haven't), without 
 adopting new
 syntax, maybe we'll bite... but so far, I think using 'with' (or from) 
 and 'as'
 is an excellent contender.


 I'll repeat myself here, too <g>. The 'static import' combined with 
 'alias' has

 *exactly the same semantics*

 as 'with' 'as'. The only difference between the proposals is if there 
 are two statements or one. There is no difference in power or effect. 
 There is nothing that one can do that the other cannot.



 The semantics are not exactly the same.  Read Sean and Kris's 
 explanations again, please.  'static import' adds nothing to the what 
 this whole namespace business.  It just sharpens the compiler a bit to 
 enforce FQN for the programmer's sake.  But that is absolutely 
 unnecessary because a D programmer that wants to do that now can just 
 make sure he uses FQNs!  So what's the point of 'static import'?


 I have to disagree with this. Currently, suppose you have a module that 
 uses the toString() functions from std.string (and uses them hundreds of 
 times). Then, you decide you need to use std.date in one place to get the 
 current time. Suddenly, your module won't compile, because 
 std.date.toString() conflicts with all the other toString()s that you're 
 using. Even though you're not even using std.date.toString !

 With the static import proposal, you could just have

 import std.string;
 static import std.date;

 and then use FQNs for the single usage of date.

 This is not a contrived example, I encountered it in my second D program 
 (and I immediately thought that there were serious problems with the D 
 module system. You're telling me I have to alias std.string.toString just 
 because I want to use std.date.getUTCtime() ???). 'static import' would 
 make it possible to avoid the use of FQNs in most cases; it would enable 
 you to distinguish 'I'm going to use a function from this module' (static 
 import) from 'I'm heavily depending on this module' (normal import).

 Which is not to say that I'm favouring 'static import' in this discussion, 
 I'm simply saying that all of the proposals, including static import, are 
 an *enormous* improvement over what we have now.
Jul 11 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jul 11 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 I think you are missing the point. *sigh*. Read above. 
 Imports/namespaces make
 up what constitutes a D program.  I think it's a very central, 
 critical, and
 special to D.


 
 I certainly agree with that. What I am unconvinced of, however, is that 

 etc., do not support renaming. Only Python seems to. And only D has a 
 general purpose renaming capability.



statement which functionality-wise is pretty much like D's alias:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_9_3_1.asp
This alias directive supports the aliasing of namespaces and namespace 
members.

But I agree that renaming doesn't seem central or critical to a D 
program. At least not in a way that we would need an "import ... as ..." 
other than just D's "alias".


in where they are imported, they are not transitive. In other words, 
they are like "private import". (As everyone says D's import should be 
by default...)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 11 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Bruno Medeiros wrote:

 

 in where they are imported, they are not transitive. In other words, 
 they are like "private import". (As everyone says D's import should be 
 by default...)
 


Good point.
Jul 11 2006
prev sibling parent Lucas Goss <lgoss007 gmail.com> writes:
Bruno Medeiros wrote:

 

 in where they are imported, they are not transitive. In other words, 
 they are like "private import". (As everyone says D's import should be 
 by default...)
 




Lucas
Jul 11 2006
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:

 D already has a lot of syntax in it. We should be very careful about 
 adding more; not every convenience should have its own syntactic sugar.


Hmm... then how did we ever get MatchExpressions ? Or the new delegate 
literal syntax ? It seems like it requires an army to convince you about 
new adding features even if they are as obvious as the extra arguments 
to assert.

We should be careful about adding more syntax, but we shouldn't be 
paranoid about it. I don't want to sound rude, but you seem to be 
totally ignoring all the fine points that long time D users have stated 
in the recent discussions. What is so terrible about adding more 
convenient ways to import modules, especially if they can ease project 
maintenance and increase code readability ? Sure, you have your 'static' 
import. There are a few problems with it though. First, probably least 
important aspect is its name. What does 'static' mean here ? The 
reluctance to make it any better ? *g*

Secondly, let's examine a sample usage of the proposed syntax:

with foo.bar.baz import a, b, c, d, e, f;


Using static import, it becomes:

static import foo.bar.baz;
alias foo.bar.baz.a a;
alias foo.bar.baz.b b;
alias foo.bar.baz.c c;
alias foo.bar.baz.d d;
alias foo.bar.baz.e e;
alias foo.bar.baz.f f;


You might consider it as 'not that bad'. But think about refactoring. 
Say, you need to change the module 'foo.bar.baz' to 'foo.x.y'. With the 
proposed syntax, you just do one simple change. With 'static import', 
well... many.
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.

You want to give 'static import' a try and see how it turns out ? Why 
don't you implement the proposal instead, call it 'DMD.experimental.163' 
and see if *this one* works or not ?


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jul 10 2006
parent reply xs0 <xs0 xs0.com> writes:
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
Jul 10 2006
next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
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 :)


Actually, i just wish D imports worked like in Python. Then

import foo.bar.baz;
foo.bar.baz.a = 1;

would be legal, while

from foo.bar.baz import b;
foo.bar.baz.a = 1;

would be illegal. As I see it, one of the points about using selective 
imports is the ability to specify *exactly* what should be imported and 
no more. I wouldn't like to get access to the whole module thru FQNs 
just because I wanted a few symbols and were forced to use 'static import'.


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jul 10 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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 

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
Jul 11 2006
parent reply Dave <Dave_member pathlink.com> writes:
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 

 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 

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?
Jul 11 2006
parent reply xs0 <xs0 xs0.com> writes:
 I must strongly reinforce this statement. There is nothing wrong with 

 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 

 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
Jul 11 2006
parent reply Dave <Dave_member pathlink.com> writes:
xs0 wrote:

 

 I must strongly reinforce this statement. There is nothing wrong with 

 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 

 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
Jul 11 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
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 

 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, 

 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
Jul 11 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
 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, 

 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
Jul 11 2006
parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
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, 

 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)
Jul 11 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Walter Bright wrote:

 But *are* they the usual case? As far as I can tell, Python is the only 
 significant language that allows aliasing of import names (though the 
 Python manual calls it "binding"). (We'll set aside the C++ #define 
 trick as not a reasonable method.) I haven't seen it used in Python 
 code, though I admit I haven't seen much Python code.
 
 That's why I suggest just trying it for a while. Kris' original concerns 
 are met with the combination of 'static import' (I know, I know, should 
 think of some better keyword combination) and 'alias'. Syntax changes 
 should be done conservatively - if there's an existing way to do it, it 
 has to be used a lot to justify special syntax for it.
 
 Kris brought up 'goto' - sure, we can do a 'while' loop with a goto, but 
 loops are so very, very common that special syntactic sugar for it has 
 proven to be a big win.
 
 D already has a lot of syntax in it. We should be very careful about 
 adding more; not every convenience should have its own syntactic sugar.


I can see your concerns and after trying out some ideas I partly agree.

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. And I think 
this syntax would be nice:

(1)
import std.math.*;
import std.stdio.writefln;
import std.stdio.writef;

While the list style is nice in that it's a little less typing, and the 
static is somewhat nice in that it doesn't break existing things:

(2)
static import math;
import std.stdio : writefln, writef;

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

But I definitely agree about the private issue. Visible private modules 
are evil. So if you find out why private is like it is in C++, please 
let us know so we can fix those issues that cause private to be broken 
before more dams break and water seeps under the bridge.

Lucas
Jul 10 2006
next sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <e8unve$2qjl$1 digitaldaemon.com>, Lucas Goss says...


 D already has a lot of syntax in it. We should be very careful about 
 adding more; not every convenience should have its own syntactic sugar.


I can see your concerns and after trying out some ideas I partly agree.

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.

Example using selective imports:





See?  Just think of it differently.  In fact that's how I would likely do it to
represent the two different sections clearly. Maybe add () to the "with"
statement to make it consistent with D's use of "with"?




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.



(1)
import std.math.*;
import std.stdio.writefln;
import std.stdio.writef;

While the list style is nice in that it's a little less typing, and the 
static is somewhat nice in that it doesn't break existing things:



Why use '*'?  That unnecessary since the current import already does that.



(2)
static import math;
import std.stdio : writefln, writef;



So you don't mind the "static" in front of import?



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.

-JJR
Jul 10 2006
parent Lucas Goss <lgoss007 gmail.com> writes:
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.


 ...


 
 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
Jul 11 2006
prev sibling parent reply Bill Baxter <Bill_member pathlink.com> writes:
Just wanted to join in to make 2 quick comments:

1) regarding "static import foo.bar"

People seem to saying the 'static' is rather meaningless as a word in this
context.  But think of it this way:  "static" the English word means
"stationary" "showing little changing".  In that sense a static import is an
import that doesn't change or move the name of the module being imported.
Although you're *importing* it (bringing it into the current namespace), you're
not actually *moving* it into the current namespace.  foo.bar.baz remains
foo.bar.baz, rather than being moved into the current namespace as baz.  So in
that sense, "static" actually seems to make some sense here, I think.  (not
saying I like it, though.  "Static" is still overused, and fqn imports should be
the default and have the simplest syntax, since they're the safest from a SE
standpoint.)

2) Regarding ways to avoid new keywords 'as' or 'from'

'=' is another option for avoiding new 'as'/'from' keywords.

Someone suggetsed 
import foo.bar : mybar
I think as an alternative to 
import foo.bar as mybar

I kind of like that as a way to avoid introducing a keyword, but maybe '=' would
make more sense as in:

import mybar = foo.bar

Or to list a few aliases:

import foo.bar : mybaz = baz, myblip = blip, bork

Or use 'with' in conjuction with '='
with foo.bar import mybaz = baz, myblip = blip, bork

I'm not wild about 'import' getting stuck in the middle there, but it's the same
thing as Python's:  
from foo.bar import mybaz as baz, myblip as blip, bork
which most people don't seem to mind.  Using '=' makes it shorter though, and
much shorter than it would be with 'alias' stuck in there somehow.

I think Python's import rules are generally quite sane, and D could do far worse
than to copy Python's rules wholesale; however, note that Python 2.5 is getting
a new feature related to importing relative to the current module:
http://docs.python.org/dev/whatsnew/pep-328.html
--

Actually -- back to the avoiding new keywords discussion -- I'm curious why you
can't just introduce 'as' or 'from' as new keywords that are ONLY keywords in an
import statement.  Assuming you make the grammatical construct always begin with
'import' the production rules for the grammar should still be simple.

Regards,
'bill the lurker'
Jul 10 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Just wanted to join in to make 2 quick comments:
 
 1) regarding "static import foo.bar"
 
 People seem to saying the 'static' is rather meaningless as a word in this
 context.  But think of it this way:  "static" the English word means
 "stationary" "showing little changing".  In that sense a static import is an
 import that doesn't change or move the name of the module being imported.
 Although you're *importing* it (bringing it into the current namespace), you're
 not actually *moving* it into the current namespace.  foo.bar.baz remains
 foo.bar.baz, rather than being moved into the current namespace as baz.  So in
 that sense, "static" actually seems to make some sense here, I think.  (not
 saying I like it, though.  "Static" is still overused, and fqn imports should
be
 the default and have the simplest syntax, since they're the safest from a SE
 standpoint.)


I thought 'static' would be ideal because it has already had its meaning 
overloaded into oblivion anyway <g>.


 2) Regarding ways to avoid new keywords 'as' or 'from'
 
 '=' is another option for avoiding new 'as'/'from' keywords.


Yes, using symbols is probably better than new keywords.



 I think Python's import rules are generally quite sane, and D could do far
worse
 than to copy Python's rules wholesale; however, note that Python 2.5 is getting
 a new feature related to importing relative to the current module:
 http://docs.python.org/dev/whatsnew/pep-328.html


Thanks for the reference. Looks like they found that relative imports 
were a mistake, and want to move to absolute imports. D already uses an 
absolute import model, so there's no issue there for us.



 Actually -- back to the avoiding new keywords discussion -- I'm curious why you
 can't just introduce 'as' or 'from' as new keywords that are ONLY keywords in
an
 import statement.  Assuming you make the grammatical construct always begin
with
 'import' the production rules for the grammar should still be simple.


The jargon for that is "context sensitive keywords". They prevent things 
like a clean lexical pass, mess up syntax highlighters, and generally 
cause trouble.
Jul 11 2006
parent Bill Baxter <Bill_member pathlink.com> writes:
In article <e8vlsn$19vu$1 digitaldaemon.com>, Walter Bright says...

Bill Baxter wrote:

 I think Python's import rules are generally quite sane, and D could do far
worse
 than to copy Python's rules wholesale; however, note that Python 2.5 is getting
 a new feature related to importing relative to the current module:
 http://docs.python.org/dev/whatsnew/pep-328.html


Thanks for the reference. Looks like they found that relative imports 
were a mistake, and want to move to absolute imports. D already uses an 
absolute import model, so there's no issue there for us.


I think D also has the edge on Python in terms of uniform syntax for importing
modules as well as functions.  In Python to import a module it's:

import modulename.submodulename

but for functions or classes in a module you have to do

from modulename import functionname

D's way is better.  No matter what 'blah' is, if you want to import it, it's
'import blah.blah.blah;'.  

Python's lack of a standard, simple way to provide module-level protection is
annoying, too.  It makes it hard to tuck your implementation details out of the
way.  For example, if module A uses some.really.massive.library in it's
implementation and imports lots of symbols from it, and I "import A", then all
the symbols A imported are visible as "A.___".  It makes it difficult to
differentiate between A's implementation details and A's exports.  Users just
see both thrown together in a big bag.

So really I should have said "You could do a lot worse than copying Python, but
you can definitely do a lot better." :-)


 Actually -- back to the avoiding new keywords discussion -- I'm curious why you
 can't just introduce 'as' or 'from' as new keywords that are ONLY keywords in
an
 import statement.  Assuming you make the grammatical construct always begin
with
 'import' the production rules for the grammar should still be simple.


The jargon for that is "context sensitive keywords". They prevent things 
like a clean lexical pass, mess up syntax highlighters, and generally 
cause trouble.


Been too long since I took a compiler course.  But I guess I can see how it's
nice to be able to declare something unequivocally a keyword as early as
possible in the lexing phase.  Thanks for the answer.

--Bill
Jul 11 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 [...]
 [...]


In reply to Walter, Kris, Derek and all who argue on the merits of 
"import X; alias X A;" vs "import X as A;"

Once we have FQN import, which by the looks of it we'll have pretty soon 
(hopefully not with the syntax "static import" though), we'll be able to 
do something which is the first thing I've wanted to do with a FQN 
import: devise a one-line macro of some sort that would FQN import all 
modules of a project. Fortunately, a macro of some sort won't even be 
necessary, we can do it with proper D. Just make a file allfqn.d with 
the contents:

   module allfqn;

   static import mod.foo;
   static import mod.bar;
   static import math.whatever;
   static import math.whatever2;
   static import gfx.whatever;
   static import gfx.whatever2;
   ...

then just do a regular import of all.d in other files:

   module foo;

   import allfqn;

Then the equivalent of:
   import MOD.FOO as BAR;
becomes just:
   alias MOD.FOO BAR;
instead of:
   static import MOD.FOO;
   alias MOD.FOO BAR;

thus this whole debate of one syntax being 2 times wordier than the 
other becomes a non-issue? It has for me, unless there is some other issue.

This behavior of having all project entities(names) automatically 

quite sensible approach. And perhaps this should even be the standard 
among D programs.

[*] How is it in Python and Ruby? (I do not know those languages well) 
Or in any other language you know with such similar structured 
hierarchical namespacing?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 09 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bruno Medeiros wrote:

 This behavior of having all project entities(names) automatically 

 quite sensible approach. And perhaps this should even be the standard 
 among D programs.
 
 [*] How is it in Python and Ruby? (I do not know those languages well) 
 Or in any other language you know with such similar structured 
 hierarchical namespacing?
 
 


I've reviewed Python's import rules previously:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39396

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 09 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Kirk McDonald wrote:

 Bruno Medeiros wrote:

 This behavior of having all project entities(names) automatically 

 quite sensible approach. And perhaps this should even be the standard 
 among D programs.

 [*] How is it in Python and Ruby? (I do not know those languages well) 
 Or in any other language you know with such similar structured 
 hierarchical namespacing?


 
 I've reviewed Python's import rules previously:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39396
 


How does Python determine module names, and map modules to files (or 
vice-versa)?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 10 2006
next sibling parent Dan <Dan_member pathlink.com> writes:
Sorry, I still don't understand what the hubbub is about with Imports?

My understanding was that you put classes in the files named the same.  This is
intelligent design at it's finest.  Why would you WANT to import bla.blorg as
bob?
Jul 10 2006
prev sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bruno Medeiros wrote:

 Kirk McDonald wrote:
 

 Bruno Medeiros wrote:


 This behavior of having all project entities(names) automatically 

 quite sensible approach. And perhaps this should even be the standard 
 among D programs.

 [*] How is it in Python and Ruby? (I do not know those languages 
 well) Or in any other language you know with such similar structured 
 hierarchical namespacing?


 I've reviewed Python's import rules previously:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39396


 
 How does Python determine module names, and map modules to files (or 
 vice-versa)?
 


In the simple case, the file "foo.py" is mapped to the module "foo". 
When you attempt the import the module, Python searches something called 
the "Python path," which is a list of directories. Normally, this is 
just set to the current directory, the location(s) of the standard 
library, and the standard "site-packages" directory, where add-on 
libraries live. Python being Python, this list can be altered at runtime.

Python can accept other kinds of files as modules. .pyc files are 
bytecode-compiled Python code; .pyd, .dll, and/or .so files are compiled 
C (or C++, or D) extensions.

Python also has the concept of a "package," not unlike D. However, 
Python's packages are slightly more sophisticated than D's. Each 
directory in the package has a special "__init__.py" file which defines 
what the other components of the package are. This file is also a 
full-fledged Python source file, so you can do any number of things when 
just the /package/ is imported. It acts as a standard single point of 
access for the entire package.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 10 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:

 [*] How is it in Python and Ruby? (I do not know those languages well) 


http://docs.python.org/ref/import.html
Jul 10 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 kris wrote:

 The use of alias, regarding imports, should very likely be kept to a 
 bare minimum in anything other than Q&D development. Ideally zero.


 
 I really don't understand your pov. I can't help but think you regard 
 alias as like C++'s #define:
 
     alias foo bar;
     #define bar foo
 
 Such #define's I would agree are a terrible hack that don't belong in 
 professional code. But aliasing isn't like that, it's a sane and 
 well-behaved replacement.


I think Kris was merely suggesting that the need for a separate alias 
declaration for each import was the problem, not the idea of aliasing 
itself.  If a particular module imports 10 others, that's 10 separate 
aliases required as well, and there's no good way to write them in a way 
that makes for easy readability and maintenance.  This is the point he 
was trying to make below.


 It's like the use of goto ~ use it where it can really help, but 
 otherwise consider alternatives instead. I don't know what kind of 
 development-scales you have in mind for D, but I'll happily testify 
 that a boatload of aliases littering the imports would have no place 
 in any project I'm responsible for; nor in those of the people I 
 learned from. Here's why:

 Quantities of alias do little but complicate ones comprehension of the 
 code. Having a second-step (import then alias) is not only messy for 
 each import, it does nothing to /encourage/ smart usage of namespace 
 seperation. In fact, the extra step will likely discourage everyone 
 but the diehards from using anything but the current global namespace, 
 and we'll end up right back at square one.


 
 With the "static import", there is no longer any possibility of name 
 collisions, so we're not at square one. With no aliases, fully qualified 
 module contents lookup will be needed.


As above, the issue here was the need for a separate alias line to 
accomplish what was suggested by the "as" syntax, not the aliasing 
concept itself.


 At that point, the language would be lacking. And why? This is all 
 about maturity and usability of the language in specific areas. Why 
 the rollback to something that can be considered "arcane" instead?


 
 I don't see it as arcane or a workaround. Symbolic aliasing is a very 
 powerful feature - yet it's very simple.


And I think we all agree here.


 Hey ~ if you'd actually roll in the changes, I'd be happy to make them 
 myself ... I'd add both selective import and the "as" variation ~ a 
 flexible combination to handle all cases, including the one Derek 
 astutely pointed out. No aliases required by the user:

 // import as we know it today, and with a required prefix "locale."
 import lib.text.locale;
 import lib.text.locale as locale;

 // selective import of one entity, and alternatively with an alias
 import lib.text.locale.Time;
 import lib.text.locale.Time as otherTime;

 ==================================


 
 But those *are* aliases. It's just using a different keyword, "as" 
 instead of "alias", and a slightly rearranged syntax. So what's the 
 difference between:
 
 import lib.text.locale.Time as otherTime;
 
 and:
 
 alias lib.text.locale.Time otherTime;
 
 ? Absolutely none, unless I am totally misunderstanding your proposal.


The alias version actually requires two lines, given current compiler 
behavior:

import lib.text.locale;
alias  lib.text.locale locale;

(I'm focusing on the module "as" syntax here since it's what was 
discussed above)

I think Kris is saying that although the "as" syntax just syntactic 
sugar for the above, it's also more readable and more maintainable.  And 
its presence as a language feature would encourage use of what is a good 
programming practice--anything too unwieldy will only be common among 
the truly fastidious.


 Okay. Let's reflect for a moment?

 The functionality is there, but the syntax could probably be better? 
 There's a number of other posts proposing the use of "with" and so on, 
 which look rather promising (from Kirk & Derek):

 with lib.text.locale import Time, Date;

 Seems pretty darned clear what's going on there. Seems to me that's a 
 much more user-focused solution for selective imports. Let's combine 
 this with a means to import an entire module under a prefix, as we've 
 previously seen:

      // import as we know it today
 import lib.text.locale;
 auto time = new Time;

      // "locale." prefix required (great for IFTI modules)
 import lib.text.locale as locale;
 auto utc = locale.utcTime();
 auto dst = locale.daylightSavings();

      // selective import
 with lib.text.locale import Time, Date;
 auto time = new Time;
 auto date = new Date;

      // selective import with alias
 with lib.text.locale import Time, Date as MyDate;
 auto time = new Time;
 auto date = new MyDate;

 ==================================

 How about it?


 
       // "locale." prefix required (great for IFTI modules)
 static import lib.text.locale;
 alias lib.text.locale locale;
 auto utc = locale.utcTime();
 auto dst = locale.daylightSavings();


Assuming just the static import line, symbols must be fully qualified, 
yes?  So to allow just a "locale." prefix the additional alias line is 
still required?  This doesn't seem to address Kris' concerns regarding 
maintenance and readability.


      // selective import
 static import lib.text.locale;
 alias lib.text.locale.Time Time;
 alias lib.text.locale.Date Date;
 auto time = new Time;
 auto date = new Date;
 
      // selective import with alias
 static import lib.text.locale;
 alias lib.text.locale.Time Time;
 alias lib.text.locale.Date MyDate;
 auto time = new Time;
 auto date = new MyDate;
 
 These are semantically identical. The "static import" is a bit ugly 
 looking, ok. It's a little wordier, ok. But it does work and produces 
 exactly the results you asked for.


A normal import followed by an alias works nearly as well as the above, 
too, but neither is nearly as elegant as the "as" syntax, which I 
believe is a significant issue here.  If you don't mind my asking, 
what's wrong with Kris' proposal?  Are there parsing issues, do you feel 
there's a problem with its impact on code readability, etc?


 Let's harken back to the special regexp syntax I tried out a few months 
 ago. It was a bit of syntactic sugar that reduced typing significantly. 
 But it was soundly rejected by the community as adding complexity (in 
 the form of more language to learn) while actually adding little to no 
 extra power.


Regarding the Regexp syntax, my only personal objection was to the 
bindings the default implementation created between runtime and standard 
library code (and I remember this being an issue for Kris as well). 
Another issue I remember was that the current Regexp implementation 
lacks robust Unicode support, and tying a specific (arguably lacking) 
implementation into the language didn't appeal to some.  But I don't 
remember anyone complaining about the need to learn more language 
syntax.  Perhaps that was after I stopped paying close attention to the 
discussion as things degenerated?


 The "with" and "as" syntaxes add no power - they just save a little 
 typing at the expense of adding more complexity to the grammar. Is that 
 a worthwhile tradeoff? I don't know, but my inclination is to be 
 conservative about such things.


I think this may be the crux of the issue.  Kris is approaching things 
from a user's standpoint while you're approaching things from an 
implementer's standpoint.  I believe Kris feels strongly about this 
because it appears to provide a good bit of additional clarity and 
utility (in the form of reduced maintenance and encouraging good 
programming practice) for an apparently small amount of additional 
complexity on the compiler side.  You, however, see little point in 
adding this complexity if it doesn't provide anything that is not 
technically possible now.  Is this correct?

You said to John R. that you do listen to convincing arguments and I 
know this is true from experience, but we're at the point with 1.0 
features where the outstanding issues concern utility and 
aesthetics--areas where it's nearly impossible to make an argument on 
purely logical grounds.  I think one aspect of D that most of us find 
incredibly appealing is its sense of aesthetics--the language tends to 
naturally encourage the production of elegant code--and it's clear you 
agree that this results in code that has fewer bugs and is more easily 
maintainable than its C++/Java/whatever counterpart.

Kris' argument, to me, seems built on this ideal by attempting to 
provide simple extensions that would further enhance what many of us see 
as the primary strength of this language.  Therefore, I don't understand 
the resistance to his suggestions, and I'm at a loss for how to back up 
an argument that can only be made on aesthetic, predictive, and 
hypothetical grounds.  I believe, as Kris does, that his suggestions 
would reduce maintenance cost and to do so in a way that seems 
consistent with the design goals of this language.  But until D gets to 
the point where it is actually used for large projects over a period of 
years, it will be difficult to point at a use case and say "if we'd have 
had this feature these problems would not have occurred."  Here, I can 
only defer to Kris' experience, supported by my own, and say that I 
believe his suggestions are good ones and that they would more than 
justify their presence when D reaches this level of maturity.


 I suggest trying out the "static import" for a while. See how it works 
 and looks.


I can tell you right now that I don't like the way "static import" 
looks, and I'm not terribly happy that I would need to continue 
maintaining a separate "alias" line for each import.  And that won't 
change with experience.  Might I ask why "static import" was chosen as 
the syntax for this feature?  Prepending "static" to "import" doesn't 
convey any meaning to me as a user about what's actually happening, so I 
can only conclude that this syntax was chosen because it's easy to 
implement and doesn't add any new keywords to the language?  I don't 
suppose any subset of Kris' suggestions could be implemented for 
comparison?  Or perhaps GDC would make a more appropriate testing ground 
for user-driven feature requests?  You've suggested we try out "static 
import" for a while, but that hardly puts Kris' proposal on equal 
footing for comparison.  And I personally don't want to feel I'm 
settling for "static import" simply because it was the only option we 
were offered.


Sean
Jul 09 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Sean Kelly wrote:

 I can tell you right now that I don't like the way "static import" 
 looks, and I'm not terribly happy that I would need to continue 
 maintaining a separate "alias" line for each import.  And that won't 
 change with experience.  Might I ask why "static import" was chosen as 
 the syntax for this feature?


I'm afraid that it was my suggestion originally:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39407


 Prepending "static" to "import" doesn't 
 convey any meaning to me as a user about what's actually happening, so I 
 can only conclude that this syntax was chosen because it's easy to 
 implement and doesn't add any new keywords to the language?  


That was in fact why I suggested it. Reaction to it has been so negative 
that I'm wishing I'd thought of something else. :-)


 I don't 
 suppose any subset of Kris' suggestions could be implemented for 
 comparison?  Or perhaps GDC would make a more appropriate testing ground 
 for user-driven feature requests?  You've suggested we try out "static 
 import" for a while, but that hardly puts Kris' proposal on equal 
 footing for comparison.  And I personally don't want to feel I'm 
 settling for "static import" simply because it was the only option we 
 were offered.


I actually feel the best solution is full-on Python-style imports, with 
"from" and "as", and "import" meaning FQN import. The only thing I think 
is stopping it is the introduction of two new keywords and the fact that 
this change in semantics would totally break essentially all existing 
code. By suggesting "static import" it leaves the old meaning for 
import, which does not break quite as much code. Alternatively, we could 
introduce some other new keyword like "qualified" to make "qualified 
import", though this isn't really that nice *either*.

Another suggestion for a way to represent FQN import that someone had 
was an "fqnimport" keyword (quite unlikely to be used in any existing code).

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 09 2006
parent reply Sean Kelly <sean f4.ca> writes:
Kirk McDonald wrote:

 
 I actually feel the best solution is full-on Python-style imports, with 
 "from" and "as", and "import" meaning FQN import. The only thing I think 
 is stopping it is the introduction of two new keywords and the fact that 
 this change in semantics would totally break essentially all existing 
 code.


Why is that?  Wouldn't the old import syntax still be available?  Or are 
you concerned about the addition of 'from', 'with', or 'as' as keywords?


Sean
Jul 09 2006
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Sean Kelly wrote:

 Kirk McDonald wrote:

 I actually feel the best solution is full-on Python-style imports, 
 with "from" and "as", and "import" meaning FQN import. The only thing 
 I think is stopping it is the introduction of two new keywords and the 
 fact that this change in semantics would totally break essentially all 
 existing code.


 
 Why is that?  Wouldn't the old import syntax still be available?  Or are 
 you concerned about the addition of 'from', 'with', or 'as' as keywords?


No, I am saying I prefer pure fully-qualified imports, the way Python 
does it. I'm saying it would have been better if D had done this originally:

module foo;
int bar = 20;

module mymodule;
import foo;

writefln(bar); // ERROR!
writefln(foo.bar); // Okay

The point of FQN imports is that you cannot introduce a name into the 
current namespace without explicitly saying (at least once) where it 
came from.

But this would obviously break existing code if it were changed now. 
Therefore, a new, different form of "import" is required to mean FQN 
import. I suggested "static import," with the reaction we have seen.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 09 2006
prev sibling parent reply John Reimer <John_member pathlink.com> writes:
An excellent post.  I feel much the same as Sean about the reason it is so
difficult to "convince" in relation to the import syntax issue.  It is about
aesthetics to a great extent.  But I think the aesthetics are very important in
this situation because it decides how D appears to those trying to understand
the language.

I aslo share Seans feelings concerning the alias attribute.  "alias" is a great
addition to the D langauge.  Perhaps I was unclear in my last response to
Walter: alias, in itself, is not a hack in the general case.  But I believe it
is laborious and ugly when used in the context of modules and imports.

D should be elegant.  Using alias and static import comes across as a verbose
workaround when one is working with multiple module imports; in all other cases,
it may be equivalent, but I think it's just plain ugly in comparison to the
alternative syntax using with/as or from/as.  It accomplishes something that
could be greatly simplified with an addition of a minor syntax expansion.

-JJR

In article <e8rk68$1fat$1 digitaldaemon.com>, Sean Kelly says...

Walter Bright wrote:

 kris wrote:

 The use of alias, regarding imports, should very likely be kept to a 
 bare minimum in anything other than Q&D development. Ideally zero.


 
 I really don't understand your pov. I can't help but think you regard 
 alias as like C++'s #define:
 
     alias foo bar;
     #define bar foo
 
 Such #define's I would agree are a terrible hack that don't belong in 
 professional code. But aliasing isn't like that, it's a sane and 
 well-behaved replacement.


I think Kris was merely suggesting that the need for a separate alias 
declaration for each import was the problem, not the idea of aliasing 
itself.  If a particular module imports 10 others, that's 10 separate 
aliases required as well, and there's no good way to write them in a way 
that makes for easy readability and maintenance.  This is the point he 
was trying to make below.


<snip great post content>
Jul 09 2006
parent Dave <Dave_member pathlink.com> writes:
John Reimer wrote:

 An excellent post.  I feel much the same as Sean about the reason it is so
 difficult to "convince" in relation to the import syntax issue.  It is about
 aesthetics to a great extent.  But I think the aesthetics are very important in
 this situation because it decides how D appears to those trying to understand
 the language.
 
 I aslo share Seans feelings concerning the alias attribute.  "alias" is a great
 addition to the D langauge.  Perhaps I was unclear in my last response to
 Walter: alias, in itself, is not a hack in the general case.  But I believe it
 is laborious and ugly when used in the context of modules and imports.
 
 D should be elegant.  Using alias and static import comes across as a verbose
 workaround when one is working with multiple module imports; in all other
cases,
 it may be equivalent, but I think it's just plain ugly in comparison to the
 alternative syntax using with/as or from/as.  It accomplishes something that
 could be greatly simplified with an addition of a minor syntax expansion.
 


Excellent summation.


 -JJR
 
 In article <e8rk68$1fat$1 digitaldaemon.com>, Sean Kelly says...

 Walter Bright wrote:

 kris wrote:

 The use of alias, regarding imports, should very likely be kept to a 
 bare minimum in anything other than Q&D development. Ideally zero.


 I really don't understand your pov. I can't help but think you regard 
 alias as like C++'s #define:

     alias foo bar;
     #define bar foo

 Such #define's I would agree are a terrible hack that don't belong in 
 professional code. But aliasing isn't like that, it's a sane and 
 well-behaved replacement.


 I think Kris was merely suggesting that the need for a separate alias 
 declaration for each import was the problem, not the idea of aliasing 
 itself.  If a particular module imports 10 others, that's 10 separate 
 aliases required as well, and there's no good way to write them in a way 
 that makes for easy readability and maintenance.  This is the point he 
 was trying to make below.


 
 <snip great post content>
Jul 09 2006
prev sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:

 kris wrote:

      // "locale." prefix required (great for IFTI modules)
 import lib.text.locale as locale;
 auto utc = locale.utcTime();
 auto dst = locale.daylightSavings();

      // selective import
 with lib.text.locale import Time, Date;
 auto time = new Time;
 auto date = new Date;

      // selective import with alias
 with lib.text.locale import Time, Date as MyDate;
 auto time = new Time;
 auto date = new MyDate;

 ==================================

 How about it?


 
       // "locale." prefix required (great for IFTI modules)
 static import lib.text.locale;
 alias lib.text.locale locale;
 auto utc = locale.utcTime();
 auto dst = locale.daylightSavings();
 
      // selective import
 static import lib.text.locale;
 alias lib.text.locale.Time Time;
 alias lib.text.locale.Date Date;
 auto time = new Time;
 auto date = new Date;
 
      // selective import with alias
 static import lib.text.locale;
 alias lib.text.locale.Time Time;
 alias lib.text.locale.Date MyDate;
 auto time = new Time;
 auto date = new MyDate;
 
 These are semantically identical. The "static import" is a bit ugly 
 looking, ok. It's a little wordier, ok. But it does work and produces 
 exactly the results you asked for.


Are they really semantically identical ?



with lib.text.locale import Time, Date;
auto time = new Time;
auto date = new Date;

auto foo  = new lib.text.locale.Foo;    // error




static import lib.text.locale;
alias lib.text.locale.Time Time;
alias lib.text.locale.Date Date;
auto time = new Time;
auto date = new Date;

auto foo  = new lib.text.locale.Foo;    // no error



If I understand the 'static import' proposal correctly, these are not 
equivalent :)

Anyway, what is being discussed here is what Python has been doing for 
quite some time. The following seems to work: 
http://docs.python.org/ref/import.html


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jul 09 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
Andrei Khropov wrote:

 Walter Bright wrote:
 

 There's another way - have a different kind of import declaration, say,
 precede it with static:

 	static import foo;

 which will make the symbols in foo available, but only if they are explicitly
 qualified. Then one could access bar in foo by either:

 	foo.bar();

 or:

 	alias foo.bar bar;
 	bar();

 but not:

 	bar();	// error, undefined symbol

 The advantage of this is it is a bit more flexible and more consistent with
 the way the rest of D lookups work.


 
 That's what I was talking about in
 http://www.digitalmars.com/d/archives/digitalmars/D/39348.html
 
 Finally got a feedback from Walter :-)
 
 Looking forward to see this in future releases.
 
 "as" would be nice too but it's just syntactic sugar for fqn import + alias.
 


Yes, but the syntactic sugar in this case might be a lot of bang for the 
buck if it's easy to implement along with allowing specific symbols to 
be imported. 'as' is much easier for newbies to D to grasp, turns 2 
lines of code into one *and* makes it easier for maintainers to spot as 
they scan the imports (because aliases can and will be buried anywhere).
Jul 08 2006
parent reply kris <foo bar.com> writes:
Dave wrote:

 Andrei Khropov wrote:
 

 Walter Bright wrote:


 There's another way - have a different kind of import declaration, say,
 precede it with static:

     static import foo;

 which will make the symbols in foo available, but only if they are 
 explicitly
 qualified. Then one could access bar in foo by either:

     foo.bar();

 or:

     alias foo.bar bar;
     bar();

 but not:

     bar();    // error, undefined symbol

 The advantage of this is it is a bit more flexible and more 
 consistent with
 the way the rest of D lookups work.



 That's what I was talking about in
 http://www.digitalmars.com/d/archives/digitalmars/D/39348.html

 Finally got a feedback from Walter :-)

 Looking forward to see this in future releases.

 "as" would be nice too but it's just syntactic sugar for fqn import + 
 alias.




hehe -- this wandering thread goes all over the ng. I'm moving this 
reply out of the gdc forum :)

the problem with the above is that the static-import would require all 
references to be "fully" prefixed. It looks ok on paper, but you'd end 
up with some very long names for references. It could be limited to use 
only the module name itself, and discard the path prefix e.g.

static import lib.text.locale.time;

auto time = new lib.text.locale.time.Time;  // where did the Time go?
auto time = new time.Time;                  // module name only
-----

but perhaps a better solution for this would arguably be

import lib.text.locale.time as quick;      // use a name of your choice

auto time = new quick.Time;
-----

Unfortunately this introduces a new keyword, "as".

There again, both these approaches are importing all symbols from the 
module; whereas the other proposal that most people seemed to like is an 
extension to /selectively/ import instead:

import lib.text.locale.time.Time;

auto time = new Time;
-----

This is clearly more explicit. There are benefits to both approaches, 
and while I'm in the latter camp as being the better overall solution, 
I'd really like to see both available :)

For example, as a library writer, I'm one of those who leans heavily 
toward grouping so-called free-functions into a namespace of their own. 
e.g. I'll use a struct to wrap a set of otherwise free-functions, just 
to give them a namespace. Some folk here would have a fit over that, but 
I do it to avoid the subtle namespace clashes that arise within other 
libraries. I'd be happy to drop that particular habit/workaround if the 
static-import were available (with the module-name-prefix only i.e. "new 
time.Time;"). This would work particularly well for nifti modules (Nifty 
Implicit Function Template Instantiation), and would avoid the one 
problem with using structs for namespace resolution -- which is that the 
linker cannot strip unused functions from a struct, so you may end up 
with some unused code in the executable. That kind of thing should 
really be avoided for nifti modules in particular.

But the selective import is still the more elegant solution, in my book. 
So if we had only one choice, you know where I'd be. If we can have 
both, then that would be even better. Too many choices is often a bad 
thing, but it this case each approach appears to have true merit, and 
its own place in creating robust and easy-to-manage code. If one or the 
other has a serious technical impediment, then that would have to be 
considered - obviously.



 Yes, but the syntactic sugar in this case might be a lot of bang for the 
 buck if it's easy to implement along with allowing specific symbols to 
 be imported. 'as' is much easier for newbies to D to grasp, turns 2 
 lines of code into one *and* makes it easier for maintainers to spot as 
 they scan the imports (because aliases can and will be buried anywhere).


Yes, I fully agree. Alias can be useful, but it shouldn't be overused 
(like goto, I suppose; or champagne). It would be hard to keep track of 
imports that are aliased here and there, and the extra step involved 
(with adding an alias) would hardly be conducive to /encouraging/ 
namespace seperation. These might seem like small concerns to some, but 
within large bodies of code they really do make a notable difference.
Jul 08 2006
next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
kris wrote:

 the problem with the above is that the static-import would require all
 references to be "fully" prefixed. It looks ok on paper, but you'd end
 up with some very long names for references. It could be limited to use
 only the module name itself, and discard the path prefix e.g.
 
 static import lib.text.locale.time;
 
 auto time = new lib.text.locale.time.Time;  // where did the Time go?
 auto time = new time.Time;                  // module name only
 -----
 
 but perhaps a better solution for this would arguably be
 
 import lib.text.locale.time as quick;      // use a name of your choice
 
 auto time = new quick.Time;
 -----
 
 Unfortunately this introduces a new keyword, "as".
 


Why not use "in"?

import lib.text.locale.time in quick;

To me, the meaning is quite clear, though it may not be as plain as "as". Maybe
it helps to think of namespaces: "import 'lib.text.locale.time' into the 'quick'
namespace".
Jul 08 2006
prev sibling next sibling parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
kris wrote:


 
 Unfortunately this introduces a new keyword, "as".


I don't think it's really a problem.

"as" syntax is very readable and is familiar to people who know Python.
 
-- 
AKhropov
Jul 08 2006
prev sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 06:15:11 +1000, kris <foo bar.com> wrote:



 but perhaps a better solution for this would arguably be

 import lib.text.locale.time as quick;      // use a name of your choic=


e

 auto time =3D new quick.Time;
 -----

 Unfortunately this introduces a new keyword, "as".

 There again, both these approaches are importing all symbols from the =


 =


 module; whereas the other proposal that most people seemed to like is =


an  =


 extension to /selectively/ import instead:

 import lib.text.locale.time.Time;

 auto time =3D new Time;
 -----

 This is clearly more explicit. There are benefits to both approaches, =


 =


 and while I'm in the latter camp as being the better overall solution,=


  =


 I'd really like to see both available :)


Yes, both are needed to disabiguate members.

   import std.string.find;
   import std.regexp.find;

   find(text1, text2);  // Which 'find' do you want?

So we still need a way to do this. Maybe the 'as' keyword is not a bad  =

idea here...


   import std.string.find;
   import std.regexp.find as re_find;

   re_find(text1, text2);

-- =

Derek Parnell
Melbourne, Australia
Jul 08 2006
prev sibling next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:

 Walter Bright wrote:
 

 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.



 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue 
 quite elegantly.



 I like this one better, too.


 
 
 There's another way - have a different kind of import declaration, say, 
 precede it with static:
 
     static import foo;
 
 which will make the symbols in foo available, but only if they are 
 explicitly qualified. Then one could access bar in foo by either:
 
     foo.bar();
 
 or:
 
     alias foo.bar bar;
     bar();
 
 but not:
 
     bar();    // error, undefined symbol
 
 The advantage of this is it is a bit more flexible and more consistent 
 with the way the rest of D lookups work.


I'm glad you liked my "static import" idea, but I have an additional 
suggestion.

Say we have the following module:

[foo.d]
module foo;

int bar;
char[] baz;
// ... and other names...

// EOF

I propose the following:

import foo;
     Does what it does now.

static import foo;
     Requires names in foo to be fully-qualified. Also, this should be 
implicitly private, so that modules that in turn import this one do not 
get the name "foo" inserted into their own namespaces.

static import foo with bar, baz;
     The names bar and baz can be accessed directly, any other names 
must be fully-qualified. (This reuses the 'with' keyword.) This should 
be synonymous with:

     static import foo;
     alias foo.bar bar;
     alias foo.baz baz;

     And it is much less verbose.

static import foo with bar as boo, baz;
     foo.bar can be accessed as boo, foo.baz as baz, and any other names 
in foo must be fully qualified. This should be the same as:

     static import foo;
     alias foo.bar boo;
     alias foo.baz baz;

     And (again) it is much less verbose. This has the disadvantage of 
requiring a new keyword. The word "alias" can be used in place of "as" 
to prevent this, though I don't think it reads as well.

import foo with bar, baz;
     This would import foo using the current rules, and promote bar and 
baz to first-class names, shadowing names imported from other modules. 
Any other names in foo would remain second-class names. Analogously to 
above, this is the same as:

     import foo;
     alias foo.bar bar;
     alias foo.baz baz;

     The syntax "import foo with bar as boo;" should obviously also be 
allowed.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki
Jul 08 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 Walter Bright wrote:

 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.


 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue 
 quite elegantly.


 I like this one better, too.


 
 There's another way - have a different kind of import declaration, say, 
 precede it with static:
 
     static import foo;
 
 which will make the symbols in foo available, but only if they are 
 explicitly qualified. Then one could access bar in foo by either:
 
     foo.bar();
 
 or:
 
     alias foo.bar bar;
     bar();
 
 but not:
 
     bar();    // error, undefined symbol
 
 The advantage of this is it is a bit more flexible and more consistent 
 with the way the rest of D lookups work.


Ah, the FQN import I (and others) have been waiting for. My comment:
http://www.digitalmars.com/d/archives/digitalmars/D/28423.html

[quote:]
PROPOSAL 1, FQN import:
Introduce a new statement, identical to import, :
   fqnimport <module>;
except that it only brings the <module> entity into scope. It's child
entities will have to be accessed trough the <module> entity (by FQN then).
The keyword for this statement could be "fqnimport", or perhaps a
shorter but still descriptive name like "mimport", "importm" (for import
module)? [Right now I'm favoring "importm" but am not decided;]
[/quote]

I must contested the proposed named by Walter. "static import" seems a 
pretty crappy name, there is nothing "static" about it. Do we have to 
recycle existing keywords? I'm not very much into this phobia of 
introducing new keywords. You didn't have a problem introducing 
"scope"... :P


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 08 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:

 I must contested the proposed named by Walter. "static import" seems a 
 pretty crappy name, there is nothing "static" about it. Do we have to 
 recycle existing keywords? I'm not very much into this phobia of 
 introducing new keywords. You didn't have a problem introducing 
 "scope"... :P


Turns out, "scope" was a problem. It broke a lot of my code - a lot more 
than I'd anticipated.
Jul 08 2006
next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 11:12:07 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Bruno Medeiros wrote:

 I must contested the proposed named by Walter. "static import" seems a  
 pretty crappy name, there is nothing "static" about it. Do we have to  
 recycle existing keywords? I'm not very much into this phobia of  
 introducing new keywords. You didn't have a problem introducing  
 "scope"... :P


 Turns out, "scope" was a problem. It broke a lot of my code - a lot more  
 than I'd anticipated.


Hint: Using identifier names that have at least one upper case character  
in them reduces conflicts with D keywords.

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
prev sibling next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 Bruno Medeiros wrote:

 I must contested the proposed named by Walter. "static import" seems a 
 pretty crappy name, there is nothing "static" about it. Do we have to 
 recycle existing keywords? I'm not very much into this phobia of 
 introducing new keywords. You didn't have a problem introducing 
 "scope"... :P


 
 Turns out, "scope" was a problem. It broke a lot of my code - a lot more 
 than I'd anticipated.


Remember my Google SoC project proposal? Such a tool has the potencial 
to make such changes trivial. Just rename all names which have a name 
that has become incompatible(a keyword) to a new name:

   $ dtool  someproj rename *.scope scopefoo

In fact, couldn't DMD easily do something similar, as it already has a 
full D parser?

In any case, the good news is I will be working on such a tool, during 
the next school year (as my final degree project). :)

Hum, BTW, what lots of code did "scope" break? Phobos? I was under the 
impression you didn't have much personal code written in D.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 09 2006
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e8pl56$26u9$1 digitaldaemon.com...


 Turns out, "scope" was a problem. It broke a lot of my code - a lot more 
 than I'd anticipated.


Heh, of course, the "scope" statement came out just as I was beginning to 
write the MiniD compiler :S  Had "scope" in there quite a few times!

Okay, no one seems to like "static import."  How about "protected import"?

It fits right in with the current syntax:

public import foo; // the default
private import foo;
protected import foo; // FQN import

And it says "protected," as in "the names are protected from conflict by 
their namespace."

The only problem I'd see with this would be doing a "private protected 
import" :S
Jul 09 2006
prev sibling parent Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:

 kris wrote:

 Walter Bright wrote:


 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.


 Now that would be great. I believe selective-importing (as an option) 
 would be a boon in a number of ways ~ and would resolve this issue 
 quite elegantly.


 
 I like this one better, too.
 
 


I like it too, but I have a question: how far would it go? Would we be able to 
do this:

//----------

module a;

class Foo
{
	enum Bar { ... }
	
	struct Baz
	{
		const something = ...;
	}
}

//----------

module b;

import a.Foo.Bar;
import a.Foo.Baz.something;

//----------

Or just module members?

-- 
Carlos Santander Bernal
Jul 08 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 13:36:49 +1000, Walter Bright  
<newshound digitalmars.com> wrote:



 But the suggestions involve changing the importer code, too. I'm not  
 seeing the advantage of that over fully qualifying the references or  
 using an alias, both of which will ensure that no future imports will  
 cause name collisions.


I tend to agree with Walter on this one. The only thing that might be  
needed in a post 1.0 edition of D is some syntax help to make the job of  
tedious alias coding a lot easier.


 What can be done is something like add a warning whenever a name is  
 found using the second-class import lookup, rather than using an alias  
 or a fully qualified lookup. Then, you'll be able to easily purge your  
 code of any such, and be confident that adding other modules will not  
 break your existing code.


Not a bad idea at all.


 What can also be done is extend the import declaration to allow the .'s  
 to continue so that specific symbols can be imported.


An excellent idea because it does the job and follows the consistent look  
of D. Makes my job in Build a bit harder though ;-)

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
parent Dave <Dave_member pathlink.com> writes:
Derek Parnell wrote:

 On Sat, 08 Jul 2006 13:36:49 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:
 
 

 But the suggestions involve changing the importer code, too. I'm not 
 seeing the advantage of that over fully qualifying the references or 
 using an alias, both of which will ensure that no future imports will 
 cause name collisions.


 
 I tend to agree with Walter on this one. The only thing that might be 
 needed in a post 1.0 edition of D is some syntax help to make the job of 
 tedious alias coding a lot easier.
 

 What can be done is something like add a warning whenever a name is 
 found using the second-class import lookup, rather than using an alias 
 or a fully qualified lookup. Then, you'll be able to easily purge your 
 code of any such, and be confident that adding other modules will not 
 break your existing code.


 
 Not a bad idea at all.
 

 What can also be done is extend the import declaration to allow the 
 .'s to continue so that specific symbols can be imported.


 
 An excellent idea because it does the job and follows the consistent 
 look of D. Makes my job in Build a bit harder though ;-)
 


Completely agree.


 --Derek Parnell
 Melbourne, Australia
Jul 08 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 kris wrote:

 D imports an entire module, into the current namespace (or some 
 variation upon that). This means that any additions to the original 
 module have to be aware of the namespace usage of *any* module that 
 imports the original. Otherwise, a namespace collision will occur and 
 the combination will fail to compile. M3 import explicitly from each 
 module instead ~ you can't have such a collision. The value of that is 
 just as solid today as it was in 1989.

 One might argue that with D, one should create new modules instead of 
 extending existing ones? That's a fair point until you consider that 
 the module namespace is limited to one file, and the 'friend' aspect 
 is limited to one module (private attributes being visible within the 
 one module). Thus, D suffers this problem in a notable manner.

 I forget whether M3 supports importing into a distinct namespace or 
 not --- the "import x.y.z. as foo;" syntax -- but that can alleviate 
 related problems, and would help resolve the current D namespace 
 conflicts that are quite prevalant?


 
 import namespaces are second class citizens in D - they are easily 
 overridden by using aliases or fully qualified lookups:
 
 import a;    // defines foo()
 import b;    // defines foo()
 
 foo();        // ambiguous
 a.foo();    // doesn't matter if there's a b.foo
 b.foo();    // works
 
 alias a.foo foo;
 foo();        // works
 
 As for import x.y.z. as foo;, you can do:
 
 alias x.y.z foo;
 foo.bar();
 
 alias x.y abc;
 abc.x.bar();
 
 alias x def;
 def.y.z.bar();
 
 The alias works at any level you choose to make it. Alias can be used to 
 'import' any name into the current namespace, making it first class.
 
 The second class lookup capability is to make it easier to write quick 
 and dirty programs. Aliases or fully qualified names should be used when 
 writing large, complex apps. Think of it like using private - you 
 wouldn't bother with it for small or throwaway programs, but you 
 wouldn't think of not using it for long lived or complex apps.


I like the second class lookup capability as it leads to clear and 
predictable behavior.  And I agree that 'alias' is a very useful tool 
for handling more advanced requirements.  Kris does as well, I beleive, 
as the "import x.y.z as foo;" proposal was meant as a shorthand for:

     import x.y.z;
     alias x.y.z foo;

With the issue of whether the contents of x.y.z are visible without the 
'foo' qualifier as an open issue (IMO).

However, the current lookup rules are such that the need to alias or 
fully-qualify names is really quite common, and it is confusing for 
those new to the language.  For example:

     module modA;

     void someFunc() {}

----------

     module modB;

     private void someFunc() {}
     void doSomething() { someFunc(); }

----------

     import modA;
     import modB;

     void main()
     {
         doSomething();
         someFunc();
     }

Compiling the above gives:

     modA.d(3): function modA.someFunc conflicts with
                modB.someFunc at modB.d(3)

Thus requiring the user to fully qualify his call to someFunc even 
though the collision is with a function that he shouldn't be aware of in 
the first place.

Now I'll admit that I used to fully support the current lookup 
mechanism, but I've since used D a lot more and this issue has bitten me 
quite a bit since then.  So I decided to do some digging and discovered 
that the lookup mechanism for C++ classes (which the D mechanism is 
obviously based on) was done mostly for practical reasons to deal with 
compiling out-of-class member definitions, and that the current 
suggestion for modules in C++ includes making module-level declarations 
truly invisible to importing modules (the original post is here: 
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39072).

I have no intentions of suggesting that the import mechanism be 
fundamentally changed from how it works now, but is there any chance 
symbol lookup and visibility rules could be examined a bit before 1.0? 
I know others have brought up related problems in the past regarding 
mixin visiblity rules and such as well, and perhaps it would do to 
establish whether things could be tweaked a bit to resolve these 
complaints without pressing for a sea change?


Sean
Jul 07 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be used to  
 'import' any name into the current namespace, making it first class.


Even names that are declared 'private' in the imported module? Is that how  
you want it to work Walter? If so, why do we bother with 'private'? What's  
the point?

-- 
Derek Parnell
Melbourne, Australia
Jul 07 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:
 

 The alias works at any level you choose to make it. Alias can be used 
 to 'import' any name into the current namespace, making it first class.


 
 Even names that are declared 'private' in the imported module? Is that 
 how you want it to work Walter? If so, why do we bother with 'private'? 
 What's the point?


In class scope, access control is done *after* name lookup, not before. 
I'm concerned about confusion by reversing the order of that for module 
scope.
Jul 07 2006
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be used 
 to 'import' any name into the current namespace, making it first class.


 Even names that are declared 'private' in the imported module? Is that 
 how you want it to work Walter? If so, why do we bother with 
 'private'? What's the point?


 
 In class scope, access control is done *after* name lookup, not before. 
 I'm concerned about confusion by reversing the order of that for module 
 scope.


How much begging would it take to try for a release or two having 
private symbols invisible to the importer?  It's really much more 
intuitive, imho.  I haven't looked at this part of the front end code, 
but if it's easy, feel free to make it controllable via a compiler 
option just for the experiment's time frame.

Later,
Brad
Jul 07 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Brad Roberts wrote:

 Walter Bright wrote:

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be 
 used to 'import' any name into the current namespace, making it 
 first class.


 Even names that are declared 'private' in the imported module? Is 
 that how you want it to work Walter? If so, why do we bother with 
 'private'? What's the point?


 In class scope, access control is done *after* name lookup, not 
 before. I'm concerned about confusion by reversing the order of that 
 for module scope.


 
 How much begging would it take to try for a release or two having 
 private symbols invisible to the importer?  It's really much more 
 intuitive, imho.  I haven't looked at this part of the front end code, 
 but if it's easy, feel free to make it controllable via a compiler 
 option just for the experiment's time frame.


The problems happen when one has:

void foo(int x);
private void foo(long x);

So the first foo is found, then overload rules apply, and the second foo 
is selected.
Jul 07 2006
next sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:

 Brad Roberts wrote:


[snip]

 How much begging would it take to try for a release or two having 
 private symbols invisible to the importer?  It's really much more 
 intuitive, imho.  I haven't looked at this part of the front end code, 
 but if it's easy, feel free to make it controllable via a compiler 
 option just for the experiment's time frame.


 
 
 The problems happen when one has:
 
 void foo(int x);
 private void foo(long x);
 
 So the first foo is found, then overload rules apply, and the second foo 
 is selected.



So, in D, what does private actually mean? The verbose version if you 
wouldn't mind, with all known corner-cases noted?

I think the full explanation would help a lot, since it's often easier 
to remember the things one should not do, rather than those one should.
Jul 07 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 So, in D, what does private actually mean? The verbose version if you 
 wouldn't mind, with all known corner-cases noted?
 
 I think the full explanation would help a lot, since it's often easier 
 to remember the things one should not do, rather than those one should.


It means the same thing as in C++. It should give an error if you try to 
access a private member in another module - but the symbol is still found.
Jul 07 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 16:11:19 +1000, Walter Bright  =

<newshound digitalmars.com> wrote:


 kris wrote:

 So, in D, what does private actually mean? The verbose version if you=




  =


 wouldn't mind, with all known corner-cases noted?
  I think the full explanation would help a lot, since it's often easi=




er  =


 to remember the things one should not do, rather than those one shoul=




d.

 It means the same thing as in C++. It should give an error if you try =


to  =


 access a private member in another module - but the symbol is still  =



 found.



But currently it doesn't so does that mean currently DMD has this as a b=
ug  =

in it?

-----mod.d----
private int foo;

----test.d----
import foo;

int x =3D foo.x; // access to a private member is allowed but it shouldn=
't  =

be!!!


-- =

Derek Parnell
Melbourne, Australia
Jul 08 2006
parent Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 But currently it doesn't so does that mean currently DMD has this as a 
 bug in it?
 
 -----mod.d----
 private int foo;
 
 ----test.d----
 import foo;
 
 int x = foo.x; // access to a private member is allowed but it shouldn't 
 be!!!


Yes, it's a bug.
Jul 08 2006
prev sibling parent David Medlock <noone nowhere.com> writes:
Walter Bright wrote:

 kris wrote:
 

 So, in D, what does private actually mean? The verbose version if you 
 wouldn't mind, with all known corner-cases noted?

 I think the full explanation would help a lot, since it's often easier 
 to remember the things one should not do, rather than those one should.


 
 
 It means the same thing as in C++. It should give an error if you try to 
 access a private member in another module - but the symbol is still found.


Aside from the 'its like C++' argument, why make it visible at all?

Making these things spill over is an unnecessary chore for development, imo.

When I tell the man at Pikes Nursery I want some grass, its a lot 
different than when I say it to the undercover cop on the street corner.

-DavidM
Jul 08 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 15:18:42 +1000, kris <foo bar.com> wrote:


 Walter Bright wrote:

 Brad Roberts wrote:


 [snip]

 How much begging would it take to try for a release or two having  
 private symbols invisible to the importer?  It's really much more  
 intuitive, imho.  I haven't looked at this part of the front end code,  
 but if it's easy, feel free to make it controllable via a compiler  
 option just for the experiment's time frame.


   The problems happen when one has:
  void foo(int x);
 private void foo(long x);
  So the first foo is found, then overload rules apply, and the second  
 foo is selected.



 So, in D, what does private actually mean? The verbose version if you  
 wouldn't mind, with all known corner-cases noted?

 I think the full explanation would help a lot, since it's often easier  
 to remember the things one should not do, rather than those one should.


That why I wrote http://www.users.bigpond.com/ddparnell/attr.html but no  
one has bothered to comment it yet - including Walter whom I explicitly  
asked to.

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 That why I wrote http://www.users.bigpond.com/ddparnell/attr.html but no 
 one has bothered to comment it yet - including Walter whom I explicitly 
 asked to.


I think it's a lot better than what I wrote about it.
Jul 08 2006
parent Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 That why I wrote http://www.users.bigpond.com/ddparnell/attr.html but 
 no one has bothered to comment it yet - including Walter whom I 
 explicitly asked to.


 
 I think it's a lot better than what I wrote about it.


Yes except in a couple of places that isn't how it works!
Jul 08 2006
prev sibling parent reply kris <foo bar.com> writes:
Derek Parnell wrote:

 On Sat, 08 Jul 2006 15:18:42 +1000, kris <foo bar.com> wrote:
 

 Walter Bright wrote:


 Brad Roberts wrote:


 [snip]


 How much begging would it take to try for a release or two having  
 private symbols invisible to the importer?  It's really much more  
 intuitive, imho.  I haven't looked at this part of the front end 
 code,  but if it's easy, feel free to make it controllable via a 
 compiler  option just for the experiment's time frame.


   The problems happen when one has:
  void foo(int x);
 private void foo(long x);
  So the first foo is found, then overload rules apply, and the 
 second  foo is selected.




 So, in D, what does private actually mean? The verbose version if you  
 wouldn't mind, with all known corner-cases noted?

 I think the full explanation would help a lot, since it's often 
 easier  to remember the things one should not do, rather than those 
 one should.


 
 
 That why I wrote http://www.users.bigpond.com/ddparnell/attr.html but 
 no  one has bothered to comment it yet - including Walter whom I 
 explicitly  asked to.
 


I read it several times; it didn't seem to follow the compiler 
behaviour, which is not any fault of the messenger.
Jul 08 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 18:15:35 +1000, kris <foo bar.com> wrote:



   That why I wrote http://www.users.bigpond.com/ddparnell/attr.html





 I read it several times; it didn't seem to follow the compiler  
 behaviour, which is not any fault of the messenger.


I know it doesn't and that is exactly what I was trying to get a comment  
on. Is the documentation right or is the compiler right. In anycase, get  
the documentation right first then fix the compiler.

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
prev sibling next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Brad Roberts wrote:

 Walter Bright wrote:

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be
 used to 'import' any name into the current namespace, making it
 first class.


 Even names that are declared 'private' in the imported module? Is
 that how you want it to work Walter? If so, why do we bother with
 'private'? What's the point?


 In class scope, access control is done *after* name lookup, not
 before. I'm concerned about confusion by reversing the order of that
 for module scope.


 How much begging would it take to try for a release or two having
 private symbols invisible to the importer?  It's really much more
 intuitive, imho.  I haven't looked at this part of the front end code,
 but if it's easy, feel free to make it controllable via a compiler
 option just for the experiment's time frame.


 
 The problems happen when one has:
 
 void foo(int x);
 private void foo(long x);
 
 So the first foo is found, then overload rules apply, and the second foo
 is selected.


Ok, I think I get it: module level private in D means exactly *nothing*.

:)

How does this sound in the documentation:
"A module level function that is declared private can not be used in
another module unless there is another public function with the same name."
<- This is just crazy(or does it justsound crazy to me), IMO private
"void foo(long x);" in the above example should not be included in the
overload resolution.
Jul 07 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Ivan Senji wrote:

 How does this sound in the documentation:
 "A module level function that is declared private can not be used in
 another module unless there is another public function with the same name."
 <- This is just crazy(or does it justsound crazy to me), IMO private
 "void foo(long x);" in the above example should not be included in the
 overload resolution.


Consider the following C++ code:

struct S
{
	public void foo(long);
	private void foo(int);
};
struct T
{
	public void foo(long);
};

...

S s;
s.foo(1);	// error, foo(int) is private
T t;
t.foo(1);	// ok

Note that it sees S::foo(int) and it participates in overload resolution 
even though it is private. In other words, accessibility is checked 
after lookup and after overload resolution.
Jul 08 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 18:26:46 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Ivan Senji wrote:

 How does this sound in the documentation:
 "A module level function that is declared private can not be used in
 another module unless there is another public function with the same  
 name."
 <- This is just crazy(or does it justsound crazy to me), IMO private
 "void foo(long x);" in the above example should not be included in the
 overload resolution.


 Consider the following C++ code:

 struct S
 {
 	public void foo(long);
 	private void foo(int);
 };
 struct T
 {
 	public void foo(long);
 };

 ...

 S s;
 s.foo(1);	// error, foo(int) is private
 T t;
 t.foo(1);	// ok

 Note that it sees S::foo(int) and it participates in overload resolution  
 even though it is private. In other words, accessibility is checked  
  lookup and after overload resolution.



I'm sorry Walter but I don't give newt's fart about C++. If I wanted to  
code under the rules of C++, I'd use C++. You have changed (improved) many  
of the C++ rules in D, so why not get this one right too?

Given the example above, I'd prefer that the overload resolution rules  
would not even consider S.foo(int) because its private (from the caller's  
perspective) so it would only see the public function and resolve  
overloads based on what it is allowed to access. Thus

  s.foo(1)

should call s.foo(long) because that is the only one accessible by the  
caller anyway.

Okay, so its not C++, so what! If anyone, including existing C++ coders,  
want to code in D they should learn D.

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 I'm sorry Walter but I don't give newt's fart about C++. If I wanted to 
 code under the rules of C++, I'd use C++. You have changed (improved) 
 many of the C++ rules in D, so why not get this one right too?


I agree that D exists to fix broken rules in C++, but we need to 
understand the rationale for why they are the way they are in C++, else 
we run the risk of making a severe error. I don't recall why the access 
rules are the way they are in C++, but I do know they weren't don't that 
way for backwards compatibility.
Jul 08 2006
parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 I'm sorry Walter but I don't give newt's fart about C++. If I wanted 
 to code under the rules of C++, I'd use C++. You have changed 
 (improved) many of the C++ rules in D, so why not get this one right too?


 
 I agree that D exists to fix broken rules in C++, but we need to 
 understand the rationale for why they are the way they are in C++, else 
 we run the risk of making a severe error. I don't recall why the access 
 rules are the way they are in C++, but I do know they weren't don't that 
 way for backwards compatibility.


Please see my post here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39072

According to Daveed Vandevoorde:

    The fact that private members are inaccessible but not invisible
    regularly surprises incidental programmers. Like macros, seemingly
    unrelated declarations interfere with subsequent code. Unfortunately,
    there are good reasons for this state of affair: Without it, private
    out-of-class member declarations become impractical to parse in the
    general case.

So assuming he's right (I couldn't find the minutes of the original 
meetings to back up his claim) then the decision was made fore purely 
technical reasons, and reasons that don't seem to apply to D because of 
the different meaning of 'private'.  Daveed goes on to say:

    Module namespaces appear to be an ideal boundary for making the
    private member fully invisible: Within the module the implementer has
    full control over naming conventions and can therefore easily avoid
    interference, while outside the module the client will never
    have to implement private members. (Note that this also addresses the
    concerns of N1602 "Class Scope Using Declarations & private Members"
    by Francis Glassborow; the extension proposed therein is then no
    longer needed.)

(note that this is the proposal for modules in C++)

I know you've read the proposal, but it's available here for those who 
don't want to follow my link above:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1964.pdf


Sean
Jul 08 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 Please see my post here:


Thanks for the reference. This rule, however, long predates Daveed's 
involvement with C++. I want to do a little more research on this.
Jul 08 2006
parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Sean Kelly wrote:

 Please see my post here:


 
 Thanks for the reference. This rule, however, long predates Daveed's 
 involvement with C++. I want to do a little more research on this.


By all means.  I'd love to hear the original reasoning--Daveed's 
statement was as close as I could get from a bit of googling.


Sean
Jul 08 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 Derek Parnell wrote:

 I'm sorry Walter but I don't give newt's fart about C++. If I wanted 
 to code under the rules of C++, I'd use C++. You have changed 
 (improved) many of the C++ rules in D, so why not get this one right 
 too?


 I agree that D exists to fix broken rules in C++, but we need to 
 understand the rationale for why they are the way they are in C++, 
 else we run the risk of making a severe error. I don't recall why the 
 access rules are the way they are in C++, but I do know they weren't 
 don't that way for backwards compatibility.


 
 Please see my post here:
 
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39072
 
 According to Daveed Vandevoorde:
 
    The fact that private members are inaccessible but not invisible
    regularly surprises incidental programmers. Like macros, seemingly
    unrelated declarations interfere with subsequent code. Unfortunately,
    there are good reasons for this state of affair: Without it, private
    out-of-class member declarations become impractical to parse in the
    general case.
 


Well, that clearly states that private members should not be invisible 
in C++, but I'm having trouble understanding why. He says "Without it, 
private out-of-class member declarations become impractical to parse in 
the general case." but I don't see how or why, anyone has an example or 
clarification?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 08 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:

 Well, that clearly states that private members should not be invisible 
 in C++, but I'm having trouble understanding why. He says "Without it, 
 private out-of-class member declarations become impractical to parse in 
 the general case." but I don't see how or why, anyone has an example or 
 clarification?


I don't understand that, either.

My best guess is that getting consistent overloading results when 
changing protections was deemed by Bjarne to be less surprising, but I'm 
just guessing.
Jul 08 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Walter Bright wrote:

 Bruno Medeiros wrote:

 Well, that clearly states that private members should not be invisible 
 in C++, but I'm having trouble understanding why. He says "Without it, 
 private out-of-class member declarations become impractical to parse 
 in the general case." but I don't see how or why, anyone has an 
 example or clarification?


 
 I don't understand that, either.
 
 My best guess is that getting consistent overloading results when 
 changing protections was deemed by Bjarne to be less surprising, but I'm 
 just guessing.


Well the "become impractical to parse in the general case" part makes me 
think it would be a hard-constraint: it would make something broken or 
unfeasible, not just strange or surprising. If you find anything let us 
know.
BTW, I'm only asking this out of curiosity, I don't think it has a 
bearing on D semantics. It seems to me it would be quite feasible for D 
not to consider private overloads in its name lookup. (or any other 
non-acessible names)

Alternatively, we could require that any name overloads have the same 
protection level. It doesn't seem to be a bad solution. It is considered 
good practice that the semantics of overloaded functions are closely 
related, so maybe so should the protection level be.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 09 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:

 Sean Kelly wrote:

 Walter Bright wrote:

 Derek Parnell wrote:

 I'm sorry Walter but I don't give newt's fart about C++. If I wanted 
 to code under the rules of C++, I'd use C++. You have changed 
 (improved) many of the C++ rules in D, so why not get this one right 
 too?


 I agree that D exists to fix broken rules in C++, but we need to 
 understand the rationale for why they are the way they are in C++, 
 else we run the risk of making a severe error. I don't recall why the 
 access rules are the way they are in C++, but I do know they weren't 
 don't that way for backwards compatibility.


 Please see my post here:

 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/39072

 According to Daveed Vandevoorde:

    The fact that private members are inaccessible but not invisible
    regularly surprises incidental programmers. Like macros, seemingly
    unrelated declarations interfere with subsequent code. Unfortunately,
    there are good reasons for this state of affair: Without it, private
    out-of-class member declarations become impractical to parse in the
    general case.


 
 Well, that clearly states that private members should not be invisible 
 in C++, but I'm having trouble understanding why. He says "Without it, 
 private out-of-class member declarations become impractical to parse in 
 the general case." but I don't see how or why, anyone has an example or 
 clarification?


It seems he's implying that "truly invisible" privates would require two 
separate methods of symbol lookup: one for calling functions and another 
for defining them (if the definition occurs outside class scope where 
the function being defined should technically be invisible).  I still 
don't really see the technical hurdle there, but then I've never written 
a C++ compiler so perhaps it would turn out to be more difficult in 
practice than in theory.  Perhaps it was simply something perceived 
difficult at the time the decision was made?  In any case, I'm hoping 
Walter can find out more than I did here.


Sean
Jul 08 2006
prev sibling next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Ivan Senji wrote:

 How does this sound in the documentation:
 "A module level function that is declared private can not be used in
 another module unless there is another public function with the same
 name."
 <- This is just crazy(or does it justsound crazy to me), IMO private
 "void foo(long x);" in the above example should not be included in the
 overload resolution.


 
 Consider the following C++ code:
 
 struct S
 {
     public void foo(long);
     private void foo(int);
 };
 struct T
 {
     public void foo(long);
 };
 
 ....
 
 S s;
 s.foo(1);    // error, foo(int) is private
 T t;
 t.foo(1);    // ok
 
 Note that it sees S::foo(int) and it participates in overload resolution
 even though it is private. In other words, accessibility is checked
 after lookup and after overload resolution.


I really do understand the way C++ does things, but are you sure this is
the best/smartest way? We all know that D is not C++(a Good Thing).
I think that to most people private will mean that whatever is declared
private is invisible (in another module).

More C++ code (methods a little bit more different to avoid thinking
about implicit type conversions):

struct S
{
    public: void foo(int a){}
    private: void foo(string b){}
};

S s;
s.foo(1);
s.foo("Bla"); <- atleast in C++(unlike D) this isn't allowed, i got a
message:
"testprivate.cpp `void S::foo(std::string)' is private"

and this to me seems the wrong way around. I don't need nor want to know
about other peoples code internals, the ideal message would be:
"testprivate.cpp `no public method void S::foo(std::string)"
Jul 08 2006
next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 18:39:15 +1000, Ivan Senji  
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:


 s.foo("Bla"); <- atleast in C++(unlike D) this isn't allowed, i got a
 message:
 "testprivate.cpp `void S::foo(std::string)' is private"

 and this to me seems the wrong way around. I don't need nor want to know
 about other peoples code internals, the ideal message would be:
 "testprivate.cpp `no public method void S::foo(std::string)"


Yes a much better message.


-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Ivan Senji wrote:

 Walter Bright wrote:

 Ivan Senji wrote:

 How does this sound in the documentation:
 "A module level function that is declared private can not be used in
 another module unless there is another public function with the same
 name."
 <- This is just crazy(or does it justsound crazy to me), IMO private
 "void foo(long x);" in the above example should not be included in the
 overload resolution.


 Consider the following C++ code:

 struct S
 {
     public void foo(long);
     private void foo(int);
 };
 struct T
 {
     public void foo(long);
 };

 ....

 S s;
 s.foo(1);    // error, foo(int) is private
 T t;
 t.foo(1);    // ok

 Note that it sees S::foo(int) and it participates in overload resolution
 even though it is private. In other words, accessibility is checked
 after lookup and after overload resolution.


 
 I really do understand the way C++ does things, but are you sure this is
 the best/smartest way? We all know that D is not C++(a Good Thing).
 I think that to most people private will mean that whatever is declared
 private is invisible (in another module).
 
 More C++ code (methods a little bit more different to avoid thinking
 about implicit type conversions):
 
 struct S
 {
     public: void foo(int a){}
     private: void foo(string b){}
 };
 
 S s;
 s.foo(1);
 s.foo("Bla"); <- atleast in C++(unlike D) this isn't allowed, i got a
 message:


I should point out that I know that this is a bug in the current D
implementation, but it is a bug that would not be possible if the
compiler just didn't see/ignored private stuff from other modules.

By private stuff I also mean private classes.
Jul 08 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Ivan Senji wrote:

 How does this sound in the documentation:
 "A module level function that is declared private can not be used in
 another module unless there is another public function with the same 
 name."
 <- This is just crazy(or does it justsound crazy to me), IMO private
 "void foo(long x);" in the above example should not be included in the
 overload resolution.


 
 Consider the following C++ code:
 
 struct S
 {
     public void foo(long);
     private void foo(int);
 };
 struct T
 {
     public void foo(long);
 };
 
 ...
 
 S s;
 s.foo(1);    // error, foo(int) is private
 T t;
 t.foo(1);    // ok
 
 Note that it sees S::foo(int) and it participates in overload resolution 
 even though it is private. In other words, accessibility is checked 
 after lookup and after overload resolution.


I'm not sure this is an entirely valid example because private member 
functions in D are not inherited and therefore should never be 
considered for overload resolution in a derived class.  Assuming the new 
"truly invisible" private behavior, I would expect the lookup mechanism 
to first search the local class scope, then public/protected inherited 
scopes, then module scope, then imported module scopes.  Once a match is 
found, the overload mechanism should evaluate only the other visible 
functions at the scope of the match.  I'll admit that this sounds like 
it would require re-engineering the overload resolution code a bit, but 
I think the result would probably be more clear to the inexperienced user.


Sean
Jul 08 2006
parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 Ivan Senji wrote:

 How does this sound in the documentation:
 "A module level function that is declared private can not be used in
 another module unless there is another public function with the same 
 name."
 <- This is just crazy(or does it justsound crazy to me), IMO private
 "void foo(long x);" in the above example should not be included in the
 overload resolution.


 Consider the following C++ code:

 struct S
 {
     public void foo(long);
     private void foo(int);
 };
 struct T
 {
     public void foo(long);
 };

 ...

 S s;
 s.foo(1);    // error, foo(int) is private
 T t;
 t.foo(1);    // ok

 Note that it sees S::foo(int) and it participates in overload 
 resolution even though it is private. In other words, accessibility is 
 checked after lookup and after overload resolution.


 
 I'm not sure this is an entirely valid example because private member 
 functions in D are not inherited


I misspoke--they're not inherited in C++ either.  However, they can be 
overridden in C++ but not in D.  This is the pertinent distinction IMO.


Sean
Jul 08 2006
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:

 Brad Roberts wrote:

 Walter Bright wrote:

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be 
 used to 'import' any name into the current namespace, making it 
 first class.


 Even names that are declared 'private' in the imported module? Is 
 that how you want it to work Walter? If so, why do we bother with 
 'private'? What's the point?


 In class scope, access control is done *after* name lookup, not 
 before. I'm concerned about confusion by reversing the order of that 
 for module scope.


 How much begging would it take to try for a release or two having 
 private symbols invisible to the importer?  It's really much more 
 intuitive, imho.  I haven't looked at this part of the front end code, 
 but if it's easy, feel free to make it controllable via a compiler 
 option just for the experiment's time frame.


 
 The problems happen when one has:
 
 void foo(int x);
 private void foo(long x);
 
 So the first foo is found, then overload rules apply, and the second foo 
 is selected.


Um.. finding the second foo means that it's not invisible.  It should 
not exist as far as anything outside the module is concerned.  It's 
private, internal, period.  About the only part of existence that a 
private symbol has is in determining the size of a struct or class.  But 
beyond occupying space, it shouldn't have any interaction at all.  They 
just shouldn't exist in the symbol table at all.

Is there something about private symbols existing that all the rest of 
us are over looking that makes it important for them to be visible?

Later,
Brad
Jul 08 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 The problems happen when one has:
 
 void foo(int x);
 private void foo(long x);
 
 So the first foo is found, then overload rules apply, and the second foo 
 is selected.


This would only occur if both overloads of foo occurred in the same 
module, correct?  How is that different from the way things work now? 
Or is the issue simply that in the face of a "true" private mechanism, 
such behavior would be even more confusing?


Sean
Jul 08 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 14:47:34 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Brad Roberts wrote:



  How much begging would it take to try for a release or two having  
 private symbols invisible to the importer?  It's really much more  
 intuitive, imho.  I haven't looked at this part of the front end code,  
 but if it's easy, feel free to make it controllable via a compiler  
 option just for the experiment's time frame.


 The problems happen when one has:

 void foo(int x);
 private void foo(long x);

 So the first foo is found, then overload rules apply, and the second foo  
 is selected.


No.... what would happen if something outside the module called foo(long)  
is that foo(int) would be called due to implicit casts and that the  
module's foo(long) is invisible to the caller. It wouldn't be called  
because the caller should not be able to see it.

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Derek Parnell wrote:

 On Sat, 08 Jul 2006 14:47:34 +1000, Walter Bright
 <newshound digitalmars.com> wrote:
 

 Brad Roberts wrote:


 

  How much begging would it take to try for a release or two having
 private symbols invisible to the importer?  It's really much more
 intuitive, imho.  I haven't looked at this part of the front end
 code, but if it's easy, feel free to make it controllable via a
 compiler option just for the experiment's time frame.


 The problems happen when one has:

 void foo(int x);
 private void foo(long x);

 So the first foo is found, then overload rules apply, and the second
 foo is selected.


 
 No.... what would happen if something outside the module called
 foo(long) is that foo(int) would be called due to implicit casts and
 that the module's foo(long) is invisible to the caller. It wouldn't be
 called because the caller should not be able to see it.
 


Yes, but:
If the functions were actually:

void foo(int x);
private void foo(char[] x);

and in another module foo("bar"); the right function would be called
even though it is private.
The problem: the caller does see it if there is another function with
the same name.
Jul 08 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 18:07:34 +1000, Ivan Senji  
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:


 Derek Parnell wrote:

 On Sat, 08 Jul 2006 14:47:34 +1000, Walter Bright
 <newshound digitalmars.com> wrote:


 Brad Roberts wrote:



  How much begging would it take to try for a release or two having
 private symbols invisible to the importer?  It's really much more
 intuitive, imho.  I haven't looked at this part of the front end
 code, but if it's easy, feel free to make it controllable via a
 compiler option just for the experiment's time frame.


 The problems happen when one has:

 void foo(int x);
 private void foo(long x);

 So the first foo is found, then overload rules apply, and the second
 foo is selected.


 No.... what would happen if something outside the module called
 foo(long) is that foo(int) would be called due to implicit casts and
 that the module's foo(long) is invisible to the caller. It wouldn't be
 called because the caller should not be able to see it.


 Yes, but:
 If the functions were actually:

 void foo(int x);
 private void foo(char[] x);

 and in another module foo("bar"); the right function would be called
 even though it is private.
 The problem: the caller does see it if there is another function with
 the same name.


I agree that that is the problem. Calling foo("bar") should fail as that  
is private to the module and the caller should not be able to access it  
*BECAUSE* it is private even though the compiler can actually 'see' it.

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
next sibling parent kris <foo bar.com> writes:
Derek Parnell wrote:

 On Sat, 08 Jul 2006 18:07:34 +1000, Ivan Senji  
 <ivan.senji_REMOVE_ _THIS__gmail.com> wrote:
 

 Derek Parnell wrote:


 On Sat, 08 Jul 2006 14:47:34 +1000, Walter Bright
 <newshound digitalmars.com> wrote:


 Brad Roberts wrote:




  How much begging would it take to try for a release or two having
 private symbols invisible to the importer?  It's really much more
 intuitive, imho.  I haven't looked at this part of the front end
 code, but if it's easy, feel free to make it controllable via a
 compiler option just for the experiment's time frame.



 The problems happen when one has:

 void foo(int x);
 private void foo(long x);

 So the first foo is found, then overload rules apply, and the second
 foo is selected.



 No.... what would happen if something outside the module called
 foo(long) is that foo(int) would be called due to implicit casts and
 that the module's foo(long) is invisible to the caller. It wouldn't be
 called because the caller should not be able to see it.


 Yes, but:
 If the functions were actually:

 void foo(int x);
 private void foo(char[] x);

 and in another module foo("bar"); the right function would be called
 even though it is private.
 The problem: the caller does see it if there is another function with
 the same name.


 
 
 I agree that that is the problem. Calling foo("bar") should fail as 
 that  is private to the module and the caller should not be able to 
 access it  *BECAUSE* it is private even though the compiler can actually 
 'see' it.
 


FWIW, you've got my support to make private actually mean Private (with 
a capital P). Anything else is surely counter-intuitive; certainly seems 
to ignore any "principal of least surprise"
Jul 08 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Derek Parnell wrote:

 On Sat, 08 Jul 2006 18:07:34 +1000, Ivan Senji 
 <ivan.senji_REMOVE_ _THIS__gmail.com> wrote:
 

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 14:47:34 +1000, Walter Bright
 <newshound digitalmars.com> wrote:


 Brad Roberts wrote:



  How much begging would it take to try for a release or two having
 private symbols invisible to the importer?  It's really much more
 intuitive, imho.  I haven't looked at this part of the front end
 code, but if it's easy, feel free to make it controllable via a
 compiler option just for the experiment's time frame.


 The problems happen when one has:

 void foo(int x);
 private void foo(long x);

 So the first foo is found, then overload rules apply, and the second
 foo is selected.


 No.... what would happen if something outside the module called
 foo(long) is that foo(int) would be called due to implicit casts and
 that the module's foo(long) is invisible to the caller. It wouldn't be
 called because the caller should not be able to see it.


 Yes, but:
 If the functions were actually:

 void foo(int x);
 private void foo(char[] x);

 and in another module foo("bar"); the right function would be called
 even though it is private.
 The problem: the caller does see it if there is another function with
 the same name.


 
 I agree that that is the problem. Calling foo("bar") should fail as that 
 is private to the module and the caller should not be able to access it 
 *BECAUSE* it is private even though the compiler can actually 'see' it.
 


Exactly - and then it would (and should!) act just like if you wrapped a 
class or struct around it (and this should apply even if you declared it 
as a private static class or struct member). I mean the consistency 
considerations of this to the average dumbass user like me are huge.

The first example points this out here:

http://www.users.bigpond.com/ddparnell/attr.html

private should act the same no matter what the enclosing scope is.


 --Derek Parnell
 Melbourne, Australia
Jul 08 2006
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Derek Parnell wrote:


 On Sat, 08 Jul 2006 18:07:34 +1000, Ivan Senji
 <ivan.senji_REMOVE_ _THIS__gmail.com> wrote:
 

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 14:47:34 +1000, Walter Bright
 <newshound digitalmars.com> wrote:


 Brad Roberts wrote:



  How much begging would it take to try for a release or two having
 private symbols invisible to the importer?  It's really much more
 intuitive, imho.  I haven't looked at this part of the front end
 code, but if it's easy, feel free to make it controllable via a
 compiler option just for the experiment's time frame.


 The problems happen when one has:

 void foo(int x);
 private void foo(long x);

 So the first foo is found, then overload rules apply, and the second
 foo is selected.


 No.... what would happen if something outside the module called
 foo(long) is that foo(int) would be called due to implicit casts and
 that the module's foo(long) is invisible to the caller. It wouldn't be
 called because the caller should not be able to see it.


 Yes, but:
 If the functions were actually:

 void foo(int x);
 private void foo(char[] x);

 and in another module foo("bar"); the right function would be called
 even though it is private.
 The problem: the caller does see it if there is another function with
 the same name.


 
 I agree that that is the problem. Calling foo("bar") should fail as that
 is private to the module and the caller should not be able to access it
 *BECAUSE* it is private even though the compiler can actually 'see' it.
 


I agree, private means private.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 11 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be used 
 to 'import' any name into the current namespace, making it first class.


 Even names that are declared 'private' in the imported module? Is that 
 how you want it to work Walter? If so, why do we bother with 
 'private'? What's the point?


 
 In class scope, access control is done *after* name lookup, not before. 
 I'm concerned about confusion by reversing the order of that for module 
 scope.


In D though, 'private' always implies module visibility, whether it it 
at module scope or class scope.  If the behavior at module scope is 
changed, would it affect its behavior at class scope as well?


Sean
Jul 08 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be 
 used to 'import' any name into the current namespace, making it 
 first class.


 Even names that are declared 'private' in the imported module? Is 
 that how you want it to work Walter? If so, why do we bother with 
 'private'? What's the point?


 In class scope, access control is done *after* name lookup, not 
 before. I'm concerned about confusion by reversing the order of that 
 for module scope.


 


What's really confusing is that module private is not really private and 
that there is not consistency!


 In D though, 'private' always implies module visibility, whether it it 
 at module scope or class scope.  If the behavior at module scope is 
 changed, would it affect its behavior at class scope as well?
 
 
 Sean
Jul 08 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:

 Walter Bright wrote:

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be 
 used to 'import' any name into the current namespace, making it 
 first class.


 Even names that are declared 'private' in the imported module? Is 
 that how you want it to work Walter? If so, why do we bother with 
 'private'? What's the point?


 In class scope, access control is done *after* name lookup, not 
 before. I'm concerned about confusion by reversing the order of that 
 for module scope.


 
 In D though, 'private' always implies module visibility, whether it it 
 at module scope or class scope.  If the behavior at module scope is 
 changed, would it affect its behavior at class scope as well?


By the way, if private were changed at both module and class level, 
which I do think makes sense on some levels, this behavior would change:

     module main;

     class C
     {
     private:
         void fn() { printf( "C\n" ); }
     }

     void fn() { printf( "glob\n" ); }

     class D : C
     {
         void go() { fn(); }
     }

     void main()
     {
         D d = new D;
         d.go;
     }

Currently, this prints "C".  But if privates were truly private then I 
would expect it to either print "glob" or to get a compile error that 
two matching function were found and that D's call to 'fn' must be 
qualified by either prefixing it with a '.' or 'C.' to indicate intent.


Sean
Jul 08 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 08 Jul 2006 13:38:13 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright  
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be used  
 to 'import' any name into the current namespace, making it first class.


  Even names that are declared 'private' in the imported module? Is that  
 how you want it to work Walter? If so, why do we bother with 'private'?  
 What's the point?


 In class scope, access control is done *after* name lookup, not before.  
 I'm concerned about confusion by reversing the order of that for module  
 scope.


Well don't be concerned. It is far more confusing for something declared  
as private to be not seen as private. I believe the natural way of  
thinking for people is that some that is "private" is not to be *seen* by  
others, and thus not accessed. So I naturally think that if the compiler  
notices that something is "private" it just pretends that it didn't see it  
and acts as if it doesn't exist.

I am totally convinced that the current thinking is unnatural. That the  
compile sees something therefore ignores the wishes of the author.

-- 
Derek Parnell
Melbourne, Australia
Jul 08 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Derek Parnell wrote:

 On Sat, 08 Jul 2006 13:38:13 +1000, Walter Bright
 <newshound digitalmars.com> wrote:
 

 Derek Parnell wrote:

 On Sat, 08 Jul 2006 06:56:47 +1000, Walter Bright
 <newshound digitalmars.com> wrote:


 The alias works at any level you choose to make it. Alias can be
 used to 'import' any name into the current namespace, making it
 first class.


  Even names that are declared 'private' in the imported module? Is
 that how you want it to work Walter? If so, why do we bother with
 'private'? What's the point?


 In class scope, access control is done *after* name lookup, not
 before. I'm concerned about confusion by reversing the order of that
 for module scope.


 
 Well don't be concerned. It is far more confusing for something declared
 as private to be not seen as private. I believe the natural way of
 thinking for people is that some that is "private" is not to be *seen*
 by others, and thus not accessed. So I naturally think that if the
 compiler notices that something is "private" it just pretends that it
 didn't see it and acts as if it doesn't exist.


Exactly, the fact that something can or cannot be accessed should be
related to its visibility. (And private to me sounds like invisible).


 
 I am totally convinced that the current thinking is unnatural. That the
 compile sees something therefore ignores the wishes of the author.


Indeed!
Jul 08 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
kris wrote:

 Walter Bright wrote:

 Don Clugston wrote:


 Just Pascal, and I never liked it.
 <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 liked Pascal until I tried to write useful programs in it (this was 
 with Pascal implemented according to Wirth's book). It seems I spent 
 all my development time fighting the compiler. The language semantics 
 locked everything up so tight there was no way to get things done.

 Then I read K+R, and it was like the light coming on. The language let 
 me do what I want (casting is the magic ingredient). Despite using 
 early very buggy C compilers, I spent my time working on my algorithms 
 rather than fighting the compiler.

 Pascal vendors noticed the exodus to C, and added a whole boatload of 
 C-like extensions to Pascal to make it a usable. By then, though, it 
 was too late to interest me; I never looked at Pascal again. (The 
 other problem with all those extensions is every vendor did them 
 differently, making Pascal probably the most non-portable language in 
 existence because you *had* to use the extensions.)


 
 Eh? We're talking about the language according the Wirth here (as Walter 
 notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal 
 was designed *solely* as an educational tool, for /teaching structured 
 programming/ ... the syntax and design was never intended as a solution 
 for general-purpose systems programming. It's silly to compare it to C


Yup.  And for that I think it was well-designed.  The syntax is clear 
and free of arcane symbology, and irritating enough to use for real work 
that students are well inclined to move on when they learn a more 
professional language ;-)  The pointer syntax in Pascal drives me 
absolutely insane.


 If you want to talk about languages intended for systems-programming, 
 perhaps you should compare to Modula-2 and Modula-3 instead. Now there's 
 a great language that missed its "market window" and/or opportunity.
 
 Interesting to note that D is basically a Modula-3 clone, using C-like 
 syntax instead and adding some more op-overloading. Perhaps D could 
 adopt the more advanced 'import' capabilities from Modula-3 also? Back 
 in the dark ages, they understood such things rather well ... the design 
 in Modula-3 allows one to extend original, imported modules without fear 
 of breaking the code that imports them. What a concept <g>


Not to derail the topic, but I'm beginning to feel that the current 
symbol lookup mechanism in conjunction with visibility modifiers does a 
terrible job at separating interface from implementation.  As D is a 
module-based language, I firmly believe that I should not want to adopt 
an C/C++ style include model simply to make my private global symbols 
actually private.  I'd be interesting to see how Modula handled the 
minutiae of importing and symbol lookup.


Sean
Jul 07 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Sean Kelly wrote:


 kris wrote:

 Walter Bright wrote:

 Don Clugston wrote:


 Just Pascal, and I never liked it.
 <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 liked Pascal until I tried to write useful programs in it (this was
 with Pascal implemented according to Wirth's book). It seems I spent
 all my development time fighting the compiler. The language semantics
 locked everything up so tight there was no way to get things done.

 Then I read K+R, and it was like the light coming on. The language let
 me do what I want (casting is the magic ingredient). Despite using
 early very buggy C compilers, I spent my time working on my algorithms
 rather than fighting the compiler.

 Pascal vendors noticed the exodus to C, and added a whole boatload of
 C-like extensions to Pascal to make it a usable. By then, though, it
 was too late to interest me; I never looked at Pascal again. (The
 other problem with all those extensions is every vendor did them
 differently, making Pascal probably the most non-portable language in
 existence because you *had* to use the extensions.)


 
 Eh? We're talking about the language according the Wirth here (as Walter
 notes vis-a-vis Wirth's book). Somebody here ought to note that Pascal
 was designed *solely* as an educational tool, for /teaching structured
 programming/ ... the syntax and design was never intended as a solution
 for general-purpose systems programming. It's silly to compare it to C


 
 Yup.  And for that I think it was well-designed.  The syntax is clear
 and free of arcane symbology, and irritating enough to use for real work
 that students are well inclined to move on when they learn a more
 professional language ;-)  The pointer syntax in Pascal drives me
 absolutely insane.
 

 If you want to talk about languages intended for systems-programming,
 perhaps you should compare to Modula-2 and Modula-3 instead. Now there's
 a great language that missed its "market window" and/or opportunity.
 
 Interesting to note that D is basically a Modula-3 clone, using C-like
 syntax instead and adding some more op-overloading. Perhaps D could
 adopt the more advanced 'import' capabilities from Modula-3 also? Back
 in the dark ages, they understood such things rather well ... the design
 in Modula-3 allows one to extend original, imported modules without fear
 of breaking the code that imports them. What a concept <g>


 
 Not to derail the topic, but I'm beginning to feel that the current
 symbol lookup mechanism in conjunction with visibility modifiers does a
 terrible job at separating interface from implementation.  As D is a
 module-based language, I firmly believe that I should not want to adopt
 an C/C++ style include model simply to make my private global symbols
 actually private.  I'd be interesting to see how Modula handled the
 minutiae of importing and symbol lookup.
 
 
 Sean


Well, since a whole lot is broken in this regard already (possibly not so
much with modules as with objects though), I think a whole lot should be
rethought and preferably in conjunction with other related features such
that the functionality is complete, functional, easy and orthogonal (no
less :) ).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jul 07 2006
prev sibling parent reply Fredrik Olsson <peylow gmail.com> writes:
Sean Kelly skrev:

 kris wrote:


<snip>

 Eh? We're talking about the language according the Wirth here (as 
 Walter notes vis-a-vis Wirth's book). Somebody here ought to note that 
 Pascal was designed *solely* as an educational tool, for /teaching 
 structured programming/ ... the syntax and design was never intended 
 as a solution for general-purpose systems programming. It's silly to 
 compare it to C


 
 
 Yup.  And for that I think it was well-designed.  The syntax is clear 
 and free of arcane symbology, and irritating enough to use for real work 
 that students are well inclined to move on when they learn a more 
 professional language ;-)  The pointer syntax in Pascal drives me 
 absolutely insane.
 


Am I the only one in the world that thinks the pointer syntax in Pascal 
beats the C and D syntax every time?

I mean how hard can it be:
^foo  == a pointer type, pointing to a foo. foo* works, but * also mul.
foo^  == Whatever the pointer foo points to. *foo works, same argument.
 bar  == The pointer of bar. &bar works to, but why reuse & again?

Pascal pointer logic also reads so well from left to right. Lets say you 
want to access a struct member of a pointer in C:
foo->bar
or
(*foo).bar
Or in Pascal simply:
foo^.bar
No exceptions, no need to introduce a new operator, and no need to use 
supeflous paranteses.

Now original Pascal, or even ANSI Pascal is hideous, that I can agree 
with. But I also think that turning the blind eye on what has been done 
with Turbo Pascal and Delphi the last two decades is idiotic. Especially 
since they have been more or less the de facto standard Pascal. And thus 
what Pascal should be judged by.


// Fredrik
Jul 07 2006
parent reply Sean Kelly <sean f4.ca> writes:
Fredrik Olsson wrote:

 Sean Kelly skrev:

 kris wrote:


 <snip>

 Eh? We're talking about the language according the Wirth here (as 
 Walter notes vis-a-vis Wirth's book). Somebody here ought to note 
 that Pascal was designed *solely* as an educational tool, for 
 /teaching structured programming/ ... the syntax and design was never 
 intended as a solution for general-purpose systems programming. It's 
 silly to compare it to C



 Yup.  And for that I think it was well-designed.  The syntax is clear 
 and free of arcane symbology, and irritating enough to use for real 
 work that students are well inclined to move on when they learn a more 
 professional language ;-)  The pointer syntax in Pascal drives me 
 absolutely insane.


 Am I the only one in the world that thinks the pointer syntax in Pascal 
 beats the C and D syntax every time?
 
 I mean how hard can it be:
 ^foo  == a pointer type, pointing to a foo. foo* works, but * also mul.
 foo^  == Whatever the pointer foo points to. *foo works, same argument.
  bar  == The pointer of bar. &bar works to, but why reuse & again?


I think the ' ' in place of '&' is quote meaningful, but for the rest... 
it just didn't seem intuitive to me.  It's been quite a while, but I 
remember really feeling like I was fighting the language once I got to 
pointers.


 Now original Pascal, or even ANSI Pascal is hideous, that I can agree 
 with. But I also think that turning the blind eye on what has been done 
 with Turbo Pascal and Delphi the last two decades is idiotic. Especially 
 since they have been more or less the de facto standard Pascal. And thus 
 what Pascal should be judged by.


I was referring to original Pascal.  I've used Delphi quite a bit as 
well, and while I'm still not crazy about the updated syntax, it's 
really quite a good system to work with in general.


Sean
Jul 07 2006
parent reply Fredrik Olsson <peylow gmail.com> writes:
Sean Kelly skrev:

 Fredrik Olsson wrote:
 

 Sean Kelly skrev:


 kris wrote:


 <snip>


 Eh? We're talking about the language according the Wirth here (as 
 Walter notes vis-a-vis Wirth's book). Somebody here ought to note 
 that Pascal was designed *solely* as an educational tool, for 
 /teaching structured programming/ ... the syntax and design was 
 never intended as a solution for general-purpose systems 
 programming. It's silly to compare it to C




 Yup.  And for that I think it was well-designed.  The syntax is clear 
 and free of arcane symbology, and irritating enough to use for real 
 work that students are well inclined to move on when they learn a 
 more professional language ;-)  The pointer syntax in Pascal drives 
 me absolutely insane.


 Am I the only one in the world that thinks the pointer syntax in 
 Pascal beats the C and D syntax every time?

 I mean how hard can it be:
 ^foo  == a pointer type, pointing to a foo. foo* works, but * also mul.
 foo^  == Whatever the pointer foo points to. *foo works, same argument.
  bar  == The pointer of bar. &bar works to, but why reuse & again?


 
 
 I think the ' ' in place of '&' is quote meaningful, but for the rest... 
 it just didn't seem intuitive to me.  It's been quite a while, but I 
 remember really feeling like I was fighting the language once I got to 
 pointers.
 

 Now original Pascal, or even ANSI Pascal is hideous, that I can agree 
 with. But I also think that turning the blind eye on what has been 
 done with Turbo Pascal and Delphi the last two decades is idiotic. 
 Especially since they have been more or less the de facto standard 
 Pascal. And thus what Pascal should be judged by.


 
 
 I was referring to original Pascal.  I've used Delphi quite a bit as 
 well, and while I'm still not crazy about the updated syntax, it's 
 really quite a good system to work with in general.
 
 
 Sean


My _only_ gripe with Pascal is case insanity! Unfortunately the more I 
write in anything else, the more I fail see an excuse :).
foo := Foo.Create();
Should be legal, but as is (and far too late to fix) we are stuck with 
ugly and stupid prefixes like:
foo := TFoo.Create();
Every class in VCL being named T... is stupidity.

But that aside, Delphi and Pascal makes it easy to be productive, write 
less, and more bug free code to solve the same problem as in other 
languages.
Yet again I must point out that D really should have sets and ranges! ;)

// Fredrik
Jul 07 2006
parent Sean Kelly <sean f4.ca> writes:
Fredrik Olsson wrote:

 Yet again I must point out that D really should have sets and ranges! ;)


Ada has constrained types as well and I think it's a terrific feature. 
Perhaps 2.0 :-)


Sean
Jul 07 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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.
Jul 11 2006
prev sibling next sibling parent reply "Peter C. Chapin" <pchapin sover.net> writes:
kris <foo bar.com> wrote in news:e8kg0a$14hu$1 digitaldaemon.com:


 Ada


I'm not sure how "historical" Ada is... there is currently an active 
community of Ada users. In any case, I use Ada a fair amount. In fact, as I 
write this I have some Ada code that I'm working on open in another window.

Peter
Jul 07 2006
parent reply Sean Kelly <sean f4.ca> writes:
Peter C. Chapin wrote:

 kris <foo bar.com> wrote in news:e8kg0a$14hu$1 digitaldaemon.com:
 

 Ada


 
 I'm not sure how "historical" Ada is... there is currently an active 
 community of Ada users. In any case, I use Ada a fair amount. In fact, as I 
 write this I have some Ada code that I'm working on open in another window.


For whatever reason, Ada doesn't seem to be a terribly popular language 
for everyday programming.  It has a lot of nice features though, and 
I've always been somewhat interested in finding the time to play with it 
a bit.  In many respects it seems like a stricter version of D.

I suppose I could add to the list with:

BASIC
Prolog


Sean
Jul 07 2006
parent reply Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:

 Peter C. Chapin wrote:

 kris <foo bar.com> wrote in news:e8kg0a$14hu$1 digitaldaemon.com:


 Ada


 I'm not sure how "historical" Ada is... there is currently an active 
 community of Ada users. In any case, I use Ada a fair amount. In fact, 
 as I write this I have some Ada code that I'm working on open in 
 another window.


 
 For whatever reason, Ada doesn't seem to be a terribly popular language 
 for everyday programming.  It has a lot of nice features though, and 
 I've always been somewhat interested in finding the time to play with it 
 a bit.  In many respects it seems like a stricter version of D.
 


Isn't Ada still used (required?) for a lot of Dept. of Defense software 
in the U.S.?

I did see some postings for Java a while back, which surprised me 
because I had thought Ada was basically mandated for all DOD work, but 
maybe that still isn't the case.


 I suppose I could add to the list with:
 
 BASIC
 Prolog
 
 
 Sean
Jul 07 2006
parent Sean Kelly <sean f4.ca> writes:
Dave wrote:

 Sean Kelly wrote:

 Peter C. Chapin wrote:

 kris <foo bar.com> wrote in news:e8kg0a$14hu$1 digitaldaemon.com:


 Ada


 I'm not sure how "historical" Ada is... there is currently an active 
 community of Ada users. In any case, I use Ada a fair amount. In 
 fact, as I write this I have some Ada code that I'm working on open 
 in another window.


 For whatever reason, Ada doesn't seem to be a terribly popular 
 language for everyday programming.  It has a lot of nice features 
 though, and I've always been somewhat interested in finding the time 
 to play with it a bit.  In many respects it seems like a stricter 
 version of D.


 
 Isn't Ada still used (required?) for a lot of Dept. of Defense software 
 in the U.S.?


I believe Ada was designed on a DoD contract, so it's not surprising 
that it's used quite a bit in the military.  More generally however, Ada 
seems be the language of choice for systems that simply cannot fail, be 
they railway switches, supertanker engine systems, etc.  However, I was 
surprised to hear that C/C++ is making inroads in these areas--probably 
because so many more people know C/C++ than Ada.


Sean
Jul 07 2006
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <e8kg0a$14hu$1 digitaldaemon.com>, kris says...

Just for fun, how many folks here have hands-on experience with any of 
the following languages?

Algol
Pascal
BCPL
Ada
Modula
Simula


Pascal.  The others are greek to me. :(

I first learned Pascal back in High-School, when I started in earnest on all
this stuff.  I had some BASIC exposure up until then, but structured programming
was beyond me until I was exposed to Pascal.  I didn't stick with it though
(obviously) as I was shown C and x86 ASM by a classmate of mine about around the
same time.  So it was strictly the stuff of class projects and homework.

AFAIK, I don't think they even teach Pascal anymore. The last time I saw Pascal
was in College where my "Intro to programming in C/C++" professor used his old
slides for the course.  Needless to say, a lot of folks who were learning
programming for the first time dropped the course.  

- EricAnderton at yahoo
Jul 07 2006
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Hmmm...

AMOS Basic
C++ /*g*/



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jul 07 2006
prev sibling next sibling parent reply Rod Haper <rhaper houston.rr.com> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula



ALGOL
Pascal
Ada

I was fortunate enough to learn ALGOL-60 as my first programming 
language back in '66 running on a Burroughs B5500.  I say fortunate 
because it instilled in me good block structured programming concepts 
from the beginning.  I still have my old copy of McCracken's "A Guide to 
ALGOL Programming".  It was - and still is - a beautiful language for 
it's day.  I never got to use ALGOL-68

Now, next to D and Python, Ada is my favorite language.  And yes Ada is 
still very much alive and kicking and has a new revision - Ada2005.

-- 
Rod
Jul 07 2006
parent Rémy Mouëza <Rémy_member pathlink.com> writes:
 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula




I once played with Pascal to help someone. It has not been longer than an
afternoon.
In 2003~2004, I used the Steelman ( Ada specifications ) to evaluate D, it was
the 0.82 version by the time, and it got nearly 80 percent of the requirements,
C was something lik 53, C++ 67, and Java ( before the 1.5 version ) 72 percent.
Jul 07 2006
prev sibling next sibling parent reply Fredrik Olsson <peylow gmail.com> writes:
kris skrev:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol


Nope


 Pascal


Hobby projects since 1988, professionally since 1995. I would hardly 
classify Pascal as a historical language.


 BCPL


nope


 Ada


For a few months in 1999, army stuff.


 Modula


Only Modula-2, back in 1992 on Atari ST, and barely a few hundred lines 
of code in Objective Modula-2 this year.


 Simula


nope.


Since Pascal fits the bill I think you should also add LISP, FORTRAN, 
COBOL, and Prolog :).

// Fredrik
Jul 07 2006
parent kris <foo bar.com> writes:
Fredrik Olsson wrote:

 kris skrev:
 

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?

 Algol


 
 Nope
 

 Pascal


 
 Hobby projects since 1988, professionally since 1995. I would hardly 
 classify Pascal as a historical language.
 

 BCPL


 
 nope
 

 Ada


 
 For a few months in 1999, army stuff.
 

 Modula


 
 Only Modula-2, back in 1992 on Atari ST, and barely a few hundred lines 
 of code in Objective Modula-2 this year.
 

 Simula


 
 nope.
 
 
 Since Pascal fits the bill I think you should also add LISP, FORTRAN, 
 COBOL, and Prolog :).



hehe ... the list is comprised of pure Algol derivatives. It ignores 
those with only a little Algol influence, such as Fortran-77 and PL1 for 
example. C & C++ are a true part of the Algol family, but pretty much 
everyone here has been exposed to those.

The 'historical' attribute was a poor choice of word on my part ~ 
intended only to tie into the derivation aspect (from Algol)
Jul 07 2006
prev sibling next sibling parent Tydr Schnubbis <fake address.dude> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Turbo Pascal in high school.
Simula at the University of Oslo, where it was created.
Jul 07 2006
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Pascal


To the point that I became a beta tester for Borland for many years.. 
Pascal 6.0 through Borland Pascal 3 (I think), into the delphi series up 
through delphi 3, if I remember right.  Somewhere along the way I also 
entered the c++ compiler beta program, but left the dos/windows world 
shortly thereafter and never looked back.

Borland Pascal was a _very_ usable language, imho.  I only moved on to c 
and later c++ due to the companies I worked for.

Later,
Brad
Jul 07 2006
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
kris wrote:

 Just for fun, how many folks here have hands-on experience with any of 
 the following languages?
 
 Algol
 Pascal
 BCPL
 Ada
 Modula
 Simula


Ada
Jul 08 2006