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.


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.

would be a boon in a number of ways ~ and would resolve this issue quite elegantly.


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

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:

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

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: # with m2 import func, abcd, efgh;
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:
 
 # with m2 import func, abcd, efgh;
 
 

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:

 # with m2 import func, abcd, efgh;

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: # with m3 import func, abcd as myabcd, efgh as myefgh; or # from m3 import func, abcd as myabcd, efgh as myefgh; This align well with the non-selective import: # import lib.text.locale as locale;
 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:

 # with m2 import func, abcd, efgh;

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: # with m3 import func, abcd as myabcd, efgh as myefgh; or # from m3 import func, abcd as myabcd, efgh as myefgh;

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: # import lib.text.locale.Time; // import Time only Which can be extended in the following manner: # import lib.text.locale.Time as myTime; 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: # with m2 import func, abcd, efgh;

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: # with m2 import func, abcd, efgh;

The equivalent would be: with m2 import func as f2, abcd as f3, efgh as f4;

Just curious, why not: import from m2 func as f2, abcd as f3, efgh as f4; or import with m2 func as f2, abcd as f3, efgh as f4; because then it is more consistent both for D (all imports start with 'import') and in pure english language terms (starts with a verb instead of a preposition like other C-lineage languages do with their /include/import/using).
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: # with m2 import func, abcd, efgh;

The equivalent would be: with m2 import func as f2, abcd as f3, efgh as f4;

Just curious, why not: import from m2 func as f2, abcd as f3, efgh as f4; or import with m2 func as f2, abcd as f3, efgh as f4; because then it is more consistent both for D (all imports start with 'import') and in pure english language terms (starts with a verb instead of a preposition like other C-lineage languages do with their /include/import/using).

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 






 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





 You've seen the requested syntax for this option, Walter. Let's 




 # with m2 import func, abcd, efgh;

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

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


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 

 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 

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

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

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

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; If import consistency is deemed desirable, then #1 & #2 perhaps looks like the most appropriate in that context? Although the latter seems notably more verbose. Personally, I like your #1 due to the consistency 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;
 
 
 If import consistency is deemed desirable, then #1 & #2 perhaps looks 
 like the most appropriate in that context? Although the latter seems 
 notably more verbose. Personally, I like your #1 due to the 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 'includes' with a verb, not a preposition, so #1 just feels more natural than #3.
 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;


 If import consistency is deemed desirable, then #1 & #2 perhaps looks 
 like the most appropriate in that context? Although the latter seems 
 notably more verbose. Personally, I like your #1 due to the 
 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 'includes' with a verb, not a preposition, so #1 just feels more natural than #3.
 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'.


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


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


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


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



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


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



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

I have to admit that 'static import' syntax has one advantage over #4 on 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 Mkel  
<jmjmak utu.fi.invalid> wrote:

 Jari-Matti Mkel 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. ;)

I have to admit that 'static import' syntax has one advantage over #4 on 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 Mkel
 <jmjmak utu.fi.invalid> wrote:
 
 Jari-Matti Mkel 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. ;)

I have to admit that 'static import' syntax has one advantage over #4 on 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 Rmy Mouza <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? ;)


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


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.

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.

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.

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.

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


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


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.

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


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 "outsider" (read?: experienced C++/C#/Java user?). In any case, if it's 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.

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?
 

 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?
 

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


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?


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=

 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=


 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 digitalmars.D/39967 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 


 I agree, but this will be a major convenience, imho.

 The proposal here

 digitalmars.D/39967
 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 

 d) is consistent with how import + alias works now.
 e) are a significant convenience.
 f) keep the visual continuity of import statements for maintenance 

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



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.


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?

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,

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,

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 written in Java, C# and Python - the large and diverse libraries - 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

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.

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.

work. Nothing more should be read into it than that.

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.


 Yes, they are ubiquitous. But the renaming of imported symbols? I'm 

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. For example, you can/have to use FQN in C# w/o an 'import', but through 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 often used all over the place in a C# 'module'. 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 


 But that power already exists. The discussion is now about whether 

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 and C++ don't have, or more importantly, Java and C# _do_ have. 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.

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++, Java, Ruby or C#? They are in Python - but are they ubiquitously used in 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 the *renaming* is central or critical. Note that C, C++, Java, C#, Ruby, 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 
 the *renaming* is central or critical. Note that C, C++, Java, C#, Ruby, 
 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 aware of how Java or C# operate in this context however. I don't 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, 
 C#, Ruby, 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 aware of how Java or C# operate in this context however. I don't 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 
 aware of how Java or C# operate in this context however.  I don't 
 suppose anyone with more experience could comment?
 
 Sean

For C# it's FQN by default, but if you add the "using" keyword it brings 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 
 aware of how Java or C# operate in this context however.  I don't 
 suppose anyone with more experience could comment?

 Sean

For C# it's FQN by default, but if you add the "using" keyword it brings 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: digitalmars.D/40005 I think they by and large got it right. An interesting aside is that FQN's are pretty rare in C# as the amount 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: digitalmars.D/40005
 

Ah, I had read that post after I posted.
 I think they by and large got it right.
 

I think so too. C# imports are easier to work with than D.
 An interesting aside is that FQN's are pretty rare in C# as the amount 
 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 the *renaming* is central or critical. Note that C, C++, Java, C#, Ruby, 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 apparent! D is not C, C++, C#, or Ruby. D is not ADA, Pascal, BCPL, Modula 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 the *renaming* is central or critical. Note that C, C++, Java, C#, Ruby, etc., do not support renaming. Only Python seems to. And only D has a general purpose renaming capability.

Correction: C# does support renaming, they have using-alias-directive 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". Sidenote: C#'s using-namespace and using-alias do not create new members 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:
 
 Sidenote: C#'s using-namespace and using-alias do not create new members 
 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:
 
 Sidenote: C#'s using-namespace and using-alias do not create new members 
 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...)
 

This is why I get along with C# a lot better. 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 FQNs being automatically available in a program (it's how Java and C# work), in fact, I strongly prefer this behavior and am planning to implement it in D when we get the FQN import. (news://news.digitalmars.com:119/e8r8tt$10cf$3 digitaldaemon.com) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
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 FQNs being automatically available in a program (it's how Java and C# work), in fact, I strongly prefer this behavior and am planning to implement it in D when we get the FQN import. (news://news.digitalmars.com:119/e8r8tt$10cf$3 digitaldaemon.com)

The one problem with that may be compilation speed. I suspect that a big part of Java's compile-time and load-time problems are because of all the symbol loading it has to do for a typical class path to enable things like automatic FQN availability. At the command line, the C# compiler actually isn't that fast either for small programs, but in the IDE it seems fast because all this stuff is pre-loaded. Once you implement it, I'd be interested in how it effects compilation speed. Maybe DWT would be a good test bed for that too - there is already an all.d for that that could be easily copied and changed. If it doesn't effect things too much, then I think the Phobos distro. could use an "allfqn.d" too just for the simple expedient it would offer for teaching, and maybe things like replacing common Perl and Python scripts with D. Maybe "all.d" is too much, and could just be replaced with "commonfqn.d" + things like "mathfqn.d", etc?
Jul 11 2006
parent reply xs0 <xs0 xs0.com> writes:
 I must strongly reinforce this statement. There is nothing wrong with 
 FQNs being automatically available in a program (it's how Java and C# 
 work), in fact, I strongly prefer this behavior and am planning to 
 implement it in D when we get the FQN import. 
 (news://news.digitalmars.com:119/e8r8tt$10cf$3 digitaldaemon.com)

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

I don't think it would affect compilation speed at all. Stuff only needs to be looked up when referenced, and if referenced, it needs to be imported anyway. As for slowness of Java compilation, I'd say the biggest speed killer is the fact that the compiler is written in Java itself - Java is the least compiler-friendly language I know.. D is, of course, the best (imho). xs0
Jul 11 2006
parent reply Dave <Dave_member pathlink.com> writes:
xs0 wrote:
 
 I must strongly reinforce this statement. There is nothing wrong with 
 FQNs being automatically available in a program (it's how Java and C# 
 work), in fact, I strongly prefer this behavior and am planning to 
 implement it in D when we get the FQN import. 
 (news://news.digitalmars.com:119/e8r8tt$10cf$3 digitaldaemon.com)

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

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

I don't think that is correct for the reference compiler, because Walter's 'static import' proposal still imported the entire module (probably because the way the compiler works now is to 'load' an entire imported module, IIRC).
 As for slowness of Java compilation, I'd say the biggest speed killer is 
 the fact that the compiler is written in Java itself - Java is the least 
 compiler-friendly language I know.. D is, of course, the best (imho).
 
 
 xs0

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 
 and C# work), in fact, I strongly prefer this behavior and am 
 planning to implement it in D when we get the FQN import. 
 (news://news.digitalmars.com:119/e8r8tt$10cf$3 digitaldaemon.com)

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

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

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

I should add that I hope it doesn't effect compilation speed much if any and that could be the case, just that I don't think your reason for that is not the way things work now (again, IIRC).
 As for slowness of Java compilation, I'd say the biggest speed killer 
 is the fact that the compiler is written in Java itself - Java is the 
 least compiler-friendly language I know.. D is, of course, the best 
 (imho).


 xs0


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, 
 the C# compiler actually isn't that fast either for small programs, 
 but in the IDE it seems fast because all this stuff is pre-loaded.

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

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

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

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

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

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

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: # with module1 # import func1, Struct1, Class1; 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"? # with (module1) # import func1, Struct1, Class1; Elegance is not impossible to attain. We just have to be willing to look for it. Consistancy is perfectly attainable too. We just have to be willing to avoid tunnel vision.
(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.
 ...
 # with (module1)
 #      import func1, Struct1, Class1;
 
 Elegance is not impossible to attain. We just have to be willing to look for
it.
 Consistancy is perfectly attainable too.  We just have to be willing to avoid
 tunnel vision.
 

I understand what you're saying, but I also get what Walter is saying. This is already mostly attainable with alias, except that additionally you want selective imports. However I fail to see what (great) value selective imports have.
 
 (1)
 import std.math.*;
 import std.stdio.writefln;
 import std.stdio.writef;

 ...

Why use '*'? That unnecessary since the current import already does that.

In the line before that I was saying it would be nice if water wasn't already under the bridge, because then we could do FQN by default. If FQN was the default, then there would need to be a way to import everything. Sorry for not making that clear.
 (2)
 static import math;
 import std.stdio : writefln, writef;

So you don't mind the "static" in front of import?

I was saying I like the first way and how it lays out as opposed to the second way. Sorry for not being clear enough. I don't like the static and I'm not even sure it's necessary.
 The argument that a rename of the base library (in this case std.stdio) 
 would be a pain to update I don't think holds. A rename is a simple find 
 and replace, which most text editors do simply. The vertical layout of 
 the first for me is easier (in my opinion) to read, and anything before 
 import makes the statement more confusing (as in the static).

I'm having difficulty following what you are trying to say. The argument holds very well still because we could make our editors do a whole lot of things, but that doesn't make it right. We're talking about making a language clear and easy to understand.

I was talking about the argument of renaming the library would cause a difficulty in updating the aliases. As far as making a language clear and easy to understand, I don't see much difference in clarity with: import lib.longname.x; alias lib.longname.x.func1 func; alias lib.longname.x.Class1 class; import lib.longname.y; alias lib.longname.y.func1 func_extra; alias lib.longname.y.Class1 Class_extra; and with (lib.longname.x) import func1 as func, Class1 as class; with (lib.longname.y) import func1 as func_extra, Class1 as Class_extra; They both seem to be pretty clear. Lucas
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 available by FQN is also how Java and C# work[*], which I think is a 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 
 available by FQN is also how Java and C# work[*], which I think is a 
 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: 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 
 available by FQN is also how Java and C# work[*], which I think is a 
 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: 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 
 available by FQN is also how Java and C# work[*], which I think is a 
 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: 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: 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.

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.

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=

 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 =

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

 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=


 to remember the things one should not do, rather than those one shoul=


 It means the same thing as in C++. It should give an error if you try =

 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:

 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.

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

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

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.

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:

 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.

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:

 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.

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.

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 Rmy Mouza <Rmy_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

 Pascal

classify Pascal as a historical language.
 BCPL

 Ada

 Modula

of code in Objective Modula-2 this year.
 Simula

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 next sibling parent 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
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