www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - the point of selective importing

reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
I've been hearing everyone toss around ideas concerning how to selectively 
import symbols from a module, and how to fqn import a module, and I've 
seriously been wondering: why selectively import at all?  Assuming we get 
static import (maybe not with that keyword, but you get the point), what's 
the need for selectively importing if we can just say:

import std.stdio; // I want writefln!
static import cool.module; //Has a toString function for a special type.
static import std.string; //But most of the time I'll be converting ints and 
such to strings, so I shouldn't have to specify.

It might just be me, but IMHO you're trying to mix apples with oranges; 
either you want fully qualified imports or you want standard imports.  If 
you desperately want to mix them, then I agree with Walter in that aliases 
should be just fine; anyone with half a brain will put them right near the 
import where they can be seen; anyone who doesn't do that is just a bad 
coder.
-- 


Ameer
---
Life is either tragedy or comedy. Usually it's your choice. You can whine or 
you can laugh.
--Animorphs 
Jul 10 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ameer Armaly" <ameer_armaly hotmail.com> wrote in message 
news:e8urqt$2vb2$1 digitaldaemon.com...

 I've been hearing everyone toss around ideas concerning how to selectively 
 import symbols from a module, and how to fqn import a module, and I've 
 seriously been wondering: why selectively import at all?  Assuming we get 
 static import (maybe not with that keyword, but you get the point), what's 
 the need for selectively importing if we can just say:

 import std.stdio; // I want writefln!
 static import cool.module; //Has a toString function for a special type.
 static import std.string; //But most of the time I'll be converting ints 
 and such to strings, so I shouldn't have to specify.

 It might just be me, but IMHO you're trying to mix apples with oranges; 
 either you want fully qualified imports or you want standard imports.  If 
 you desperately want to mix them, then I agree with Walter in that aliases 
 should be just fine;

I like the way you think, Mr. Armaly. I too don't see any real value in selective imports. I do, however, like FQN imports.
 anyone with half a brain will put them right near the import where they 
 can be seen; anyone who doesn't do that is just a bad coder.

I can just see the replies to this statement now: "but in a _real_ project, aliases end up all over the file.." Right. Sure. Maybe if you have _no sense_ of coding style or consistency.
Jul 10 2006
prev sibling next sibling parent reply Bill Baxter <Bill_member pathlink.com> writes:
In article <e8urqt$2vb2$1 digitaldaemon.com>, Ameer Armaly says...
...
It might just be me, but IMHO you're trying to mix apples with oranges; 
either you want fully qualified imports or you want standard imports.  If 
you desperately want to mix them, then I agree with Walter in that aliases 
should be just fine; anyone with half a brain will put them right near the 
import where they can be seen; anyone who doesn't do that is just a bad 
coder.

Good points. But A) renaming modules is pretty common once you allow FQN import. static import module.with.a.long.name.string; alias module.with.a.long.name.string Str; It would be nice to be able to put those into one statement so that the module name doesn't have to be typed in twice. B) Sometimes you want to keep your namespace clean except for a handful of specific symbols from some module: static import module.with.a.long.name; alias module.with.a.long.name.foo Foo; alias module.with.a.long.name.bar Bar; alias module.with.a.long.name.baz Baz; That would also be easier to read,write, and maintain if module.with.a.long.name didn't appear 4 times. Granted, you could do: static import module.with.a.long.name; alias module.with.a.long.name MWLN; alias MWLN.foo Foo; alias MWLN.bar Bar; alias MWLN.baz Baz; which is better, but the full module name still appears twice, and I didn't really want MWLN or module.with.a.long.name in my namespace to begin with. However, I'm starting to agree with Walter, on that one. There probably aren't too many times when you want to import specific symbols without also wanting access to the module as a whole. In the example I gave from my python code, "from numpy import transpose as T", the truth is that I also do "import numpy as num" in that code. So I could have just said "T = num.transpose", which would be the equivalent of D's "alias num.transpose T;". That still leaves the need for some sort of way to do: static import module.with.a.long.name as MWLN; in which MWLN is the *only* symbol introduced into the current namespace. (Although I guess in the import-and-rename case 'static' would be redundant, or just incorrect since the name *is* changing.)
Jul 10 2006
next sibling parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Bill Baxter" <Bill_member pathlink.com> wrote:
 In article <e8urqt$2vb2$1 digitaldaemon.com>, Ameer Armaly says...
...
It might just be me, but IMHO you're trying to mix apples with oranges;
either you want fully qualified imports or you want standard imports.  If
you desperately want to mix them, then I agree with Walter in that aliases
should be just fine; anyone with half a brain will put them right near the
import where they can be seen; anyone who doesn't do that is just a bad
coder.

Good points. But A) renaming modules is pretty common once you allow FQN import. static import module.with.a.long.name.string; alias module.with.a.long.name.string Str; It would be nice to be able to put those into one statement so that the module name doesn't have to be typed in twice. B) Sometimes you want to keep your namespace clean except for a handful of specific symbols from some module: static import module.with.a.long.name; alias module.with.a.long.name.foo Foo; alias module.with.a.long.name.bar Bar; alias module.with.a.long.name.baz Baz; That would also be easier to read,write, and maintain if module.with.a.long.name didn't appear 4 times. Granted, you could do: static import module.with.a.long.name; alias module.with.a.long.name MWLN; alias MWLN.foo Foo; alias MWLN.bar Bar; alias MWLN.baz Baz; which is better, but the full module name still appears twice, and I didn't really want MWLN or module.with.a.long.name in my namespace to begin with. However, I'm starting to agree with Walter, on that one. There probably aren't too many times when you want to import specific symbols without also wanting access to the module as a whole. In the example I gave from my python code, "from numpy import transpose as T", the truth is that I also do "import numpy as num" in that code. So I could have just said "T = num.transpose", which would be the equivalent of D's "alias num.transpose T;". That still leaves the need for some sort of way to do: static import module.with.a.long.name as MWLN; in which MWLN is the *only* symbol introduced into the current namespace. (Although I guess in the import-and-rename case 'static' would be redundant, or just incorrect since the name *is* changing.)

I would prefer the syntax to be something akin to alias import module.with.a.long.name MWLN; which would be exactly like static import module.with.a.long.name; alias module.with.a.long.name MWLN;
Jul 11 2006
parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Rioshin an'Harthen" <rharth75 hotmail.com> wrote:

Here I am, replying to my own post... :)

 I would prefer the syntax to be something akin to

 alias import module.with.a.long.name MWLN;

 which would be exactly like

 static import module.with.a.long.name;
 alias module.with.a.long.name MWLN;

I thought about it a little more, and came up with the following: import module.name; - current import static import module.name; - require FQN import import module.name alias MN; - current import with automatic alias static import module.name alias MN; - require FQN import with automatic alias Basically thus: The import statement imports the module, and enables the use of functions, classes, etc. of the module using just the name of the function, class, etc., or through a fully qualified name. import module.name; // contains function foo foo(); // legal module.name.foo(); // legal MN.foo(); // illegal The static import statement is like the import statement, but requires the use of the fully qualified name to access functions, classes, etc. static import module.name; foo(); // illegal module.name.foo(); // legal MN.foo(); // illegal The import ... alias statement is like the import statement, but adds the alias as an optional method of calling the functions, classes, etc. import module.name alias MN; foo(); // legal module.name.foo(); // legal MN.foo(); // legal The static import ... alias statement is like the static import statement, but adds the alias as an optional method of calling the functions, classes, etc. static import module.name alias MN; foo(); // illegal module.name.foo(); // legal MN.foo(); // legal
Jul 11 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Tue, 11 Jul 2006 21:12:59 +1000, Rioshin an'Harthen  
<rharth75 hotmail.com> wrote:


 I thought about it a little more, and came up with the following:

 import module.name; - current import
 static import module.name; - require FQN import
 import module.name alias MN; - current import with automatic alias
 static import module.name alias MN; - require FQN import with automatic
 alias

Snap! This was also my suggestion ;-) Additionally, I extended this idea to also allow for selective imports of individual members from the module rather than all the members. static import in module.name alias MN member1 alias m1, member2, member3, ... ; MN.memb3() MN.m1() -- Derek Parnell Melbourne, Australia
Jul 11 2006
parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote:
 On Tue, 11 Jul 2006 21:12:59 +1000, Rioshin an'Harthen wrote:
 I thought about it a little more, and came up with the following:

 import module.name; - current import
 static import module.name; - require FQN import
 import module.name alias MN; - current import with automatic alias
 static import module.name alias MN; - require FQN import with automatic
 alias

Snap! This was also my suggestion ;-) Additionally, I extended this idea to also allow for selective imports of individual members from the module rather than all the members. static import in module.name alias MN member1 alias m1, member2, member3, ... ; MN.memb3() MN.m1()

Great minds, eh? :) I'm giving this a definite thumbs up. Sometimes, it's quite good to only import selected members (which I didn't take into account in my post - I would probably have come up with something akin to what you show).
Jul 11 2006
parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Rioshin an'Harthen" <rharth75 hotmail.com> wrote:
 "Derek Parnell" <derek psych.ward> wrote:
 On Tue, 11 Jul 2006 21:12:59 +1000, Rioshin an'Harthen wrote:
 import module.name; - current import
 static import module.name; - require FQN import
 import module.name alias MN; - current import with automatic alias
 static import module.name alias MN; - require FQN import with automatic
 alias

Snap! This was also my suggestion ;-) Additionally, I extended this idea to also allow for selective imports of individual members from the module rather than all the members. static import in module.name alias MN member1 alias m1, member2, member3, ... ; MN.memb3() MN.m1()

Great minds, eh? :) I'm giving this a definite thumbs up. Sometimes, it's quite good to only import selected members (which I didn't take into account in my post - I would probably have come up with something akin to what you show).

A little further thought into this: [<protection>] [static] import {[in]} <FQN Module> [alias <Module Alias>] {[<<Member> [alias <Member Alias>]>[, ...]]}; where [] denotes optionality, {} requiring all if one, and <> a symbol name. This would allow for example the following syntaxes: private import module.name; import module.name alias mn; import in module.name member1, member2; import in module.name alias mn member1, member2 alias m2; private static import in module.name alias mn member1 alias m1, member2 alias m2, member3 alias m3; (where I would probably write the last one as something like private static import in module.name alias mn member1 alias m1, member2 alias m2, member3 alias m3; , but I digress). It could even be considered that any occurence of alias be replaced with alias|as, where | denotes that either but not both be used, and the difference being alias allowing the use of both forms (FQN or aliased name), while as requiring the use of the aliased name. However, this would be a complexity I would not want to write into the compiler. :) But it would fill in the forms from my previous post: import module.name; foo(); // legal module.name.foo(); // legal mn.foo(); // illegal, no alias or as import module.name alias mn; foo(); // legal module.name.foo(); // legal mn.foo(); // legal import module.name as mn; foo(); // legal since not static import module.name.foo(); // illegal since "as" is used mn.foo(); // legal static import module.name; foo(); // illegal, static import module.name.foo(); // legal mn.foo(); // illegal, no alias or as static import module.name alias mn; foo(); // illegal, static import module.name.foo(); // legal mn.foo(); // legal static import module.name as mn; foo(); // illegal, static import module.name.foo(); // illegal since "as" is used mn.foo(); // legal Not that I'm proposing this distinction - I believe it is an unnecessary complication. I think "alias" is enough - we can use the fully qualified name if necessary (sometimes, it's good for code clarity to use in a function or method the fully qualified name, and then using the short form created with an alias), while using the aliased form most of the time. The import syntax could be something akin to (with the optional as in brackets): ImportDeclaration: ProtectionAttribute 'static' ImportStatement ; ProtectionAttribute ImportStatement ; 'static' ImportStatement ; ImportStatement ; ProtectionAttribute: 'private' 'public' (and whatever others deemed necessary) ImportStatement: 'import' 'in' ModuleDeclaration MemberDeclarationList 'import' ModuleDeclarationList ModuleDeclarationList: ModuleDeclaration ModuleDeclaration , ModuleDeclarationList ModuleDeclaration: ModuleName 'alias' AliasedModuleName [ModuleName 'as' AsModuleName] ModuleName MemberDeclarationList: MemberDeclaration MemberDeclaration , MemberDeclarationList MemberDeclaration: MemberName 'alias' AliasedMemberName [MemberName 'as' AsMemberName] MemberName This grammar would allow for multiple modules to be imported on one line, provided we don't try to import specific members from it, while allowing for specific members to be imported (requiring one import statement per module when only picking certain members from it).
Jul 11 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Rioshin an'Harthen wrote:
 This would allow for example the following syntaxes:
 
 private import module.name;
 import module.name alias mn;
 import in module.name member1, member2;
 import in module.name alias mn member1, member2 alias m2;
 private static import in module.name alias mn member1 alias m1, member2 
 alias m2, member3 alias m3;
 
 (where I would probably write the last one as something like
 
     private static import
         in module.name alias mn
             member1 alias m1,
             member2 alias m2,
             member3 alias m3;
 
 , but I digress).
 
 It could even be considered that any occurence of alias be replaced with 
 alias|as, where | denotes that either but not both be used, and the 
 difference being alias allowing the use of both forms (FQN or aliased name), 
 while as requiring the use of the aliased name. However, this would be a 
 complexity I would not want to write into the compiler. :)

I guess that pretty much says that it's not appropriate to incorporate such a complex syntax in D either. Remember, D is supposed to be "simple" language. :) I don't get it - why does one have to be able to access a symbol using three different naming conventions *at the same time*. Why does not 'alias' and/or 'as' imply 'static'? What's the benefit of using 'as' instead of 'alias'? Why does one need to import individual module members or alias those module members in the import statement? I think 90% of that functionality can be achieved using only two attributes/keywords: 'private' and 'alias'. Personally I would prefer 'public' over 'private' but I guess the default behaviour of imports is not going to change anymore. I might understand why you would like to have this complex syntax: to shorten/remove the annoying prefixes preceding foreign module members, but it only makes the code less robust. Consider a situation where one of the imported modules on the same namespace gets an additional public member that conflicts with another imported member. That leads to difficult exceptions logic in the import statements. I would rather make the count of public module members as small as possible and import the whole module to the top level namespace (non-static, not as/alias) or give it an own namespace (static, alias, not as). If needs be, there could also be an ability to import separate members by concatenating the member name the member name with a leading dot to the module name in the import statement. Much easier. In my experience if your having more than 1-2 conflicting members, you're doing something wrong. -- Jari-Matti
Jul 11 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 11 Jul 2006 23:20:39 +0300, Jari-Matti Mäkelä wrote:

 In my
 experience if your having more than 1-2 conflicting members, you're
 doing something wrong.

That might be true if all the modules you use are under your direct control. However, the times I've had name clashes have been due to using libraries written by other people who, independently, decided to use the same name. Thus in my code, I am forced to disambiguate them. Consider the simple situation in Phobos std.string.find std.regexp.find internal.gc.gcx.find then add the various other 'find' members in external libraries. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 12/07/2006 9:34:15 AM
Jul 11 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Derek Parnell wrote:
 On Tue, 11 Jul 2006 23:20:39 +0300, Jari-Matti Mäkelä wrote:
 
 In my
 experience if your having more than 1-2 conflicting members, you're
 doing something wrong.

That might be true if all the modules you use are under your direct control. However, the times I've had name clashes have been due to using libraries written by other people who, independently, decided to use the same name. Thus in my code, I am forced to disambiguate them. Consider the simple situation in Phobos std.string.find std.regexp.find internal.gc.gcx.find then add the various other 'find' members in external libraries.

Ok, have to admit that's true. But do you really use them all in the same module? If there's only a small amount of conflicting names, the import syntax does not have to be so incredibly complex.
Jul 11 2006
next sibling parent reply kris <foo bar.com> writes:
Jari-Matti Mäkelä wrote:
 Derek Parnell wrote:
 
On Tue, 11 Jul 2006 23:20:39 +0300, Jari-Matti Mäkelä wrote:


In my
experience if your having more than 1-2 conflicting members, you're
doing something wrong.

That might be true if all the modules you use are under your direct control. However, the times I've had name clashes have been due to using libraries written by other people who, independently, decided to use the same name. Thus in my code, I am forced to disambiguate them. Consider the simple situation in Phobos std.string.find std.regexp.find internal.gc.gcx.find then add the various other 'find' members in external libraries.

Ok, have to admit that's true. But do you really use them all in the same module? If there's only a small amount of conflicting names, the import syntax does not have to be so incredibly complex.

It can and will happen. The larger the project, the better the chance for conflicts. There's probably some logarithmic-style graph describing the relationship between the number of modules and the resulting number of potential conflicts. The issue does not really arise within small or personal projects to the same extent. Primarily because you personally have full control over the entire namespace. The syntax itself does not need to be complex at all. It's downright simple: import w.x.y.z as z; or import w.x.y.z : z; Where z represents whatever you wish the required prefix to be. No static, no alias. Looks very much like the existing import, and is almost as effortless to use. Perhaps you might like to read the "Import RFC" posted? It explains the issues in a little more depth.
Jul 11 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
kris wrote:
 Jari-Matti Mäkelä wrote:
 Derek Parnell wrote:

 On Tue, 11 Jul 2006 23:20:39 +0300, Jari-Matti Mäkelä wrote:


 In my
 experience if your having more than 1-2 conflicting members, you're
 doing something wrong.

That might be true if all the modules you use are under your direct control. However, the times I've had name clashes have been due to using libraries written by other people who, independently, decided to use the same name. Thus in my code, I am forced to disambiguate them. Consider the simple situation in Phobos std.string.find std.regexp.find internal.gc.gcx.find then add the various other 'find' members in external libraries.

Ok, have to admit that's true. But do you really use them all in the same module? If there's only a small amount of conflicting names, the import syntax does not have to be so incredibly complex.

It can and will happen. The larger the project, the better the chance for conflicts. There's probably some logarithmic-style graph describing the relationship between the number of modules and the resulting number of potential conflicts. The issue does not really arise within small or personal projects to the same extent. Primarily because you personally have full control over the entire namespace.

Of course. But I only wanted to say that this does not justify the use of a complex import statement syntax (the one Rioshin proposed). I though the whole issue now was that Rioshin's syntax is better because it requires less typing, when multiple members of the same module conflict: static import in very.long.module.name alias mn member1 alias m1, member2 alias m2, member3 alias m3; versus import very.long.module.name as mn, very.long.module.name.member1 as m1, very.long.module.name.member2 as m2, very.long.module.name.member3 as m3; IMHO the latter version is much better. Simpler compiler implementation, less syntax rules, less reserved symbols - one can easily replace 'as' with : as you said earlier. And the best of all is that this is fully backwards compatible with the current syntax. The thing I was saying was that when there's a common guideline to create as little public members to the module as possible, it's much easier to import the whole module either to the global namespace or to a custom namespace import very.long.module.name as mn; // or import very.long.module.name; and not import individual members at all (if possible). That way the syntax I proposed would not cause so much typing. AFAICS it's pretty much the same to use import module as a, module2 as b; a.foo(); b.foo(); as import module.foo as afoo, module2.foo as bfoo; afoo(); bfoo();
 The syntax itself does not need to be complex at all.

Right. I only meant that the syntax does not have to be a monster like this [<protection>] [static] import {[in]} <FQN Module> [alias <Module Alias>] {[<<Member> [alias <Member Alias>]>[, ...]]}; (I think Rioshin even forgot to include 'as' keyword to the syntax above - that would probably make it a pain to implement if it isn't already) My own proposal (actually it's partly stolen from many other proposals) is to have only [private] import <fqn module / module member> as <local module namespace / imported member name>, ...; The Derek's problem could be then solved by doing: import std.string.find as find1, std.regexp.find as find2, internal.gc.gcx.find as find3; find1(...); find2(...); find3(...); or import std.string as s, std.regexp as r, internal.gc.gcx as g; s.find(...); r.find(...); g.find(...);
 No static, no alias. Looks very much like the existing import, and is
 almost as effortless to use. Perhaps you might like to read the "Import
 RFC" posted? It explains the issues in a little more depth.

kris, I read it already. It seems that I have overlooked the name conflict issue. I'm sorry, I'm not a library guru yet. I'll try to shut up when I don't get it, but here I though a simple solution would help. I agree with you fully, but don't get it why Derek's or Rioshin's proposal is "good" in any way. -- Jari-Matti
Jul 11 2006
parent reply kris <foo bar.com> writes:
Jari-Matti Mäkelä wrote:
 kris wrote:
The syntax itself does not need to be complex at all.

Right. I only meant that the syntax does not have to be a monster like this [<protection>] [static] import {[in]} <FQN Module> [alias <Module Alias>] {[<<Member> [alias <Member Alias>]>[, ...]]};

Right. This simpler the syntax, the better (in this case). I suspect that the use of prefix-import alone would be sufficient, and the optional selective-import is somewhat redundant? I'm sure we could all think of cases where the latter would be useful, but prefix-import (call it partially-qualified-symbols if one prefers) would suffice, IMO.
No static, no alias. Looks very much like the existing import, and is
almost as effortless to use. Perhaps you might like to read the "Import
RFC" posted? It explains the issues in a little more depth.

kris, I read it already.

Yes, I realized that right after the above post. Sorry about that :(
Jul 11 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 11 Jul 2006 18:20:54 -0700, kris <foo bar.com> wrote:
 Jari-Matti Mäkelä wrote:
 kris wrote:
 The syntax itself does not need to be complex at all.

like this [<protection>] [static] import {[in]} <FQN Module> [alias <Module Alias>] {[<<Member> [alias <Member Alias>]>[, ...]]};

Right. This simpler the syntax, the better (in this case). I suspect that the use of prefix-import alone would be sufficient, and the optional selective-import is somewhat redundant?

I agree. It seems that selective-import solves the same problem (avoiding clashes) in a less comprehensive fashion than the prefix-import. Unless there is some other problem the selective-import solves? Regan
Jul 11 2006
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 12 Jul 2006 02:51:08 +0300, Jari-Matti Mäkelä wrote:

 Consider the simple situation in Phobos
 
  std.string.find
  std.regexp.find
  internal.gc.gcx.find
 
 then add the various other 'find' members in external libraries.

Ok, have to admit that's true. But do you really use them all in the same module?

Apparently, as that's how I got the error messages. ;-)
 If there's only a small amount of conflicting names, the
 import syntax does not have to be so incredibly complex.

Totally agree. Currently I'm using this sort of syntax ... import std.string; alias std.string.find str_find; alias std.string.replace str_replace; import std.regexp; alias std.regexp.find re_find; alias std.regexp.replace re_replace; import util.str; alias util.str.find utl_find; . . . re_find( ... ); . . . str_find( ... ); . . . utl_find( ... ); Yes, there has to be a better (something that is less costly to write, read, and maintain) solution. import std.string alias str; import std.regexp alias re; import util.str alias utl; . . . re.find( ... ); . . . str.find( ... ); . . . utl.find( ... ); would do nicely, thank you. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 12/07/2006 10:12:04 AM
Jul 11 2006
next sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Derek Parnell wrote:
 On Wed, 12 Jul 2006 02:51:08 +0300, Jari-Matti Mäkelä wrote:
 
 Consider the simple situation in Phobos

  std.string.find
  std.regexp.find
  internal.gc.gcx.find

 then add the various other 'find' members in external libraries.

same module?

Apparently, as that's how I got the error messages. ;-)

Yup. No problem, I was not thinking clearly here. Better get some sleep - it's already almost 4am here :)
 If there's only a small amount of conflicting names, the
 import syntax does not have to be so incredibly complex.

Totally agree. Currently I'm using this sort of syntax ... import std.string; alias std.string.find str_find; alias std.string.replace str_replace; import std.regexp; alias std.regexp.find re_find; alias std.regexp.replace re_replace; import util.str; alias util.str.find utl_find;

This is clearly an ad-hoc solution and I also use it.
 Yes, there has to be a better (something that is less costly to write,
 read, and maintain) solution.
 
  import std.string alias str;
  import std.regexp alias re;
  import util.str alias utl;
  . . .
  re.find( ... );
  . . .
  str.find( ... );
  . . .
  utl.find( ... );
 
 would do nicely, thank you.

Yay, this is exactly the same syntax I though about. I suppose we totally agree now :) -- Jari-Matti
Jul 11 2006
prev sibling next sibling parent kris <foo bar.com> writes:
Derek Parnell wrote:
 Yes, there has to be a better (something that is less costly to write,
 read, and maintain) solution.
 
  import std.string alias str;
  import std.regexp alias re;
  import util.str alias utl;
  . . .
  re.find( ... );
  . . .
  str.find( ... );
  . . .
  utl.find( ... );
 
 would do nicely, thank you.

I've yet to read something from anyone who feels this approach, in general, is not a good one. Doesn't really matter whether the symbol used is "alias", "as", ":", "=", or whatever. It is clean, elegant, trivially maintained and modified, and is simple enough to be unburdensome for a developer. This is important, if for no other reason than it tends to encourage the use of safe imports. I know I keep harping on about that; and on, and on, and on, and on, and on. Although, this is prefix-importing rather than selective-importing. The former is far and away the more important variety, IMO.
Jul 11 2006
prev sibling parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <1wb7225zjf13v.1n8u9dwecz2a8$.dlg 40tude.net>, Derek Parnell says...
On Wed, 12 Jul 2006 02:51:08 +0300, Jari-Matti Mäkelä wrote:

 Consider the simple situation in Phobos
 
  std.string.find
  std.regexp.find
  internal.gc.gcx.find
 
 then add the various other 'find' members in external libraries.

Ok, have to admit that's true. But do you really use them all in the same module?

Apparently, as that's how I got the error messages. ;-)
 If there's only a small amount of conflicting names, the
 import syntax does not have to be so incredibly complex.

Totally agree. Currently I'm using this sort of syntax ... import std.string; alias std.string.find str_find; alias std.string.replace str_replace; import std.regexp; alias std.regexp.find re_find; alias std.regexp.replace re_replace; import util.str; alias util.str.find utl_find;

I've written some code similar to this before. It worked, but it was wordy and awkward. (And it seemed to break easily, but that was probably more due to incompetent programming on my part than a weakness of D.)
 import std.string alias str;
 import std.regexp alias re;
 import util.str alias utl;

I really like that proposed syntax. (We don't /need/ new keywords, so we shouldn't need to add new ones.) I can't believe that syntax would be hard for Walter to add, so it should be added. It would be incredibly useful.
 . . .
 re.find( ... );
 . . .
 str.find( ... );
 . . .
 utl.find( ... );

would do nicely, thank you.

Yes, I think that'd be really cool. jcc7
Jul 12 2006
parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"jcc7" <jcc7_member pathlink.com> wrote:
 In article <1wb7225zjf13v.1n8u9dwecz2a8$.dlg 40tude.net>, Derek Parnell 
 says...
 import std.string alias str;
 import std.regexp alias re;
 import util.str alias utl;

I really like that proposed syntax. (We don't /need/ new keywords, so we shouldn't need to add new ones.) I can't believe that syntax would be hard for Walter to add, so it should be added. It would be incredibly useful.

The version I wrote (note that I did not like the distinction between 'alias' and 'as', which is why the 'as' was mentioned as optional) with selective imports is what I would like to have - not that I'm that likely to use selective imports, but the idea of having the option is alluring. But I'm willing to settle for aliased imports (implicitly static, mind), for which the approximate grammar would be: ImportDeclaration: 'import' ModuleList ';' ModuleList: ModuleDeclaration ModuleDeclaration ',' ModuleList ModuleDeclaration: ModuleName 'alias' AliasedName ModuleName
Jul 12 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Rioshin an'Harthen wrote:
 "jcc7" <jcc7_member pathlink.com> wrote:
 In article <1wb7225zjf13v.1n8u9dwecz2a8$.dlg 40tude.net>, Derek Parnell 
 says...
 import std.string alias str;
 import std.regexp alias re;
 import util.str alias utl;

shouldn't need to add new ones.) I can't believe that syntax would be hard for Walter to add, so it should be added. It would be incredibly useful.

The version I wrote (note that I did not like the distinction between 'alias' and 'as', which is why the 'as' was mentioned as optional) with selective imports is what I would like to have - not that I'm that likely to use selective imports

I guess the libraries are currently written so that there aren't many name conflicts and thus there's no need to use several namespaces.
 But 
 I'm willing to settle for aliased imports (implicitly static, mind), for 
 which the approximate grammar would be:
 
 ImportDeclaration:
     'import' ModuleList ';'
 
 ModuleList:
     ModuleDeclaration
     ModuleDeclaration ',' ModuleList
 
 ModuleDeclaration:
     ModuleName 'alias' AliasedName
     ModuleName

Yes, this is much simpler and perhaps also friendlier to newbies. Yet another alternative is to use => -symbol and parenthesis: import modulename => namespacename, module2; import modulename(member1, member2) => namespacename(foo, bar); import modulename(member1, member2) => foo, namespacename(bar); There are really so many possibilities. I would let Walter choose the syntax he thinks would fit best in D, but let the community decide the functional requirements. There's a nice summary thread started by Lucas there. Perhaps we can all find a consensus there. -- Jari-Matti
Jul 12 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Bill Baxter wrote:

 static import module.with.a.long.name.string;
 alias module.with.a.long.name.string Str;

import module.with.a.long.name.string as Str; This keeps "Str" and the module name and the word import on one line, making it hugely easier to grep for them.
Jul 11 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 11 Jul 2006 15:56:44 +0300, Georg Wrede <georg.wrede nospam.org>  
wrote:
 Bill Baxter wrote:

 static import module.with.a.long.name.string;
 alias module.with.a.long.name.string Str;

import module.with.a.long.name.string as Str; This keeps "Str" and the module name and the word import on one line, making it hugely easier to grep for them.

Assuming the coder wasn't a 'half sane monkey on crack' you should be able to open the file in an editor, go to the top and do a search/find on "Str", the first result should find it. Anything else is either bad programming practice or a moderately rare case where 2 things include each other and so one uses the other before it's declaration. Regan
Jul 11 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 12 Jul 2006 01:03:16 +1200, Regan Heath <regan netwin.co.nz> wrote:
 On Tue, 11 Jul 2006 15:56:44 +0300, Georg Wrede <georg.wrede nospam.org>  
 wrote:
 Bill Baxter wrote:

 static import module.with.a.long.name.string;
 alias module.with.a.long.name.string Str;

import module.with.a.long.name.string as Str; This keeps "Str" and the module name and the word import on one line, making it hugely easier to grep for them.

Assuming the coder wasn't a 'half sane monkey on crack' you should be able to open the file in an editor, go to the top and do a search/find on "Str", the first result should find it. Anything else is either bad programming practice or a moderately rare case where 2 things include each other and so one uses the other before it's declaration.

In fact a good UI should be able to take you to the declaration of a symbol with the press of a single button, like F12 in developer studio does when you have browse info enabled. Regan
Jul 11 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Regan Heath wrote:
 On Wed, 12 Jul 2006 01:03:16 +1200, Regan Heath <regan netwin.co.nz> wrote:
 
 On Tue, 11 Jul 2006 15:56:44 +0300, Georg Wrede 
 <georg.wrede nospam.org>  wrote:

 Bill Baxter wrote:

 static import module.with.a.long.name.string;
 alias module.with.a.long.name.string Str;

import module.with.a.long.name.string as Str; This keeps "Str" and the module name and the word import on one line, making it hugely easier to grep for them.

Assuming the coder wasn't a 'half sane monkey on crack' you should be able to open the file in an editor, go to the top and do a search/find on "Str", the first result should find it. Anything else is either bad programming practice or a moderately rare case where 2 things include each other and so one uses the other before it's declaration.


Personally, I do a lot of grepping to find stuff in source trees. Mostly they are recursive greps, i.e., not done within an editor. For an example, I might want to know with what names this "module.with.a.long.name.string" is imported in the tree. Of course I could create a two-line regexp for the search, but that's a lot of work. And I'd have to allow for a potential comment or empty line(s) in between, for all I know. :-( But to a more important point, "module.with.a.long.name.string" is only written once. Maintenance gets a lot easier that way.
 In fact a good UI should be able to take you to the declaration of a  
 symbol with the press of a single button, like F12 in developer studio  
 does when you have browse info enabled.

I don't know of too many that good IDEs for D.
Jul 12 2006
prev sibling parent reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Bill Baxter" <Bill_member pathlink.com> wrote in message 
news:e8v32s$65i$1 digitaldaemon.com...
 In article <e8urqt$2vb2$1 digitaldaemon.com>, Ameer Armaly says...
...
It might just be me, but IMHO you're trying to mix apples with oranges;
either you want fully qualified imports or you want standard imports.  If
you desperately want to mix them, then I agree with Walter in that aliases
should be just fine; anyone with half a brain will put them right near the
import where they can be seen; anyone who doesn't do that is just a bad
coder.

Good points. But A) renaming modules is pretty common once you allow FQN import.

back to the idea that either you import the module in to the global namespace or you deal with the full name; I just don't see this being done very often, especially with well known libraries.
 static import module.with.a.long.name.string;
 alias module.with.a.long.name.string Str;

 It would be nice to be able to put those into one statement so that the 
 module
 name doesn't have to be typed in twice.

 B) Sometimes you want to keep your namespace clean except for a handful of
 specific symbols from some module:

 static import module.with.a.long.name;
 alias module.with.a.long.name.foo Foo;
 alias module.with.a.long.name.bar Bar;
 alias module.with.a.long.name.baz Baz;

 That would also be easier to read,write, and maintain if 
 module.with.a.long.name
 didn't appear 4 times.

 Granted, you could do:
 static import module.with.a.long.name;
 alias module.with.a.long.name MWLN;
 alias MWLN.foo Foo;
 alias MWLN.bar Bar;
 alias MWLN.baz Baz;

 which is better, but the full module name still appears twice, and I 
 didn't
 really want MWLN or module.with.a.long.name in my namespace to begin with.

if the namespace is something you actually look and see "god this is cluttered with junk," so I really don't see the point. If a module is written in such a way as to force you to go to these lengths to optimally use it then it's badly written.
 However, I'm starting to agree with Walter, on that one.  There probably 
 aren't
 too many times when you want to import specific symbols without also 
 wanting
 access to the module as a whole.  In the example I gave from my python 
 code,
 "from numpy import transpose as T", the truth is that I also do "import 
 numpy as
 num" in that code.  So I could have just said "T = num.transpose", which 
 would
 be the equivalent of D's "alias num.transpose T;".

 That still leaves the need for some sort of way to do:
 static import module.with.a.long.name as MWLN;
 in which MWLN is the *only* symbol introduced into the current namespace.
 (Although I guess in the import-and-rename case 'static' would be 
 redundant, or
 just incorrect since the name *is* changing.)


 

Jul 11 2006
parent Don Clugston <dac nospam.com.au> writes:
Ameer Armaly wrote:
 "Bill Baxter" <Bill_member pathlink.com> wrote in message 
 news:e8v32s$65i$1 digitaldaemon.com...
 In article <e8urqt$2vb2$1 digitaldaemon.com>, Ameer Armaly says...
 ...
 It might just be me, but IMHO you're trying to mix apples with oranges;
 either you want fully qualified imports or you want standard imports.  If
 you desperately want to mix them, then I agree with Walter in that aliases
 should be just fine; anyone with half a brain will put them right near the
 import where they can be seen; anyone who doesn't do that is just a bad
 coder.

But A) renaming modules is pretty common once you allow FQN import.

back to the idea that either you import the module in to the global namespace or you deal with the full name; I just don't see this being done very often, especially with well known libraries.
 static import module.with.a.long.name.string;
 alias module.with.a.long.name.string Str;

 It would be nice to be able to put those into one statement so that the 
 module
 name doesn't have to be typed in twice.

 B) Sometimes you want to keep your namespace clean except for a handful of
 specific symbols from some module:

 static import module.with.a.long.name;
 alias module.with.a.long.name.foo Foo;
 alias module.with.a.long.name.bar Bar;
 alias module.with.a.long.name.baz Baz;

 That would also be easier to read,write, and maintain if 
 module.with.a.long.name
 didn't appear 4 times.

 Granted, you could do:
 static import module.with.a.long.name;
 alias module.with.a.long.name MWLN;
 alias MWLN.foo Foo;
 alias MWLN.bar Bar;
 alias MWLN.baz Baz;

 which is better, but the full module name still appears twice, and I 
 didn't
 really want MWLN or module.with.a.long.name in my namespace to begin with.

if the namespace is something you actually look and see "god this is cluttered with junk," so I really don't see the point. If a module is written in such a way as to force you to go to these lengths to optimally use it then it's badly written.

Because the problems only really happen when you import more than one module. The existing system copes well with a single import. If something in the import has the same name as the function in your primary file, they don't conflict, because the primary namespace is searched before the imported one. But, if you import from two files, you can have a naming conflict in the secondary namespace. You have no choice -- you *have* to use FQN. Currently, I would maintain that it is not possible to use unqualified names safely in any file which imports more than one module. 'static import' would make it always safe to use one non-qualified module, and an arbitrary number of FQN modules. In any other configuration, adding a new function to a module can break existing code which imports it.
Jul 11 2006
prev sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <e8urqt$2vb2$1 digitaldaemon.com>, Ameer Armaly says...
I've been hearing everyone toss around ideas concerning how to selectively 
import symbols from a module, and how to fqn import a module, and I've 
seriously been wondering: why selectively import at all?  Assuming we get 
static import (maybe not with that keyword, but you get the point), what's 
the need for selectively importing if we can just say:

import std.stdio; // I want writefln!
static import cool.module; //Has a toString function for a special type.
static import std.string; //But most of the time I'll be converting ints and 
such to strings, so I shouldn't have to specify.

There is a reason (I think repeated several times by now) why selective imports are useful: # with lib.module1.special.names # import func1, Struct1, Class2; The above func1, Struct1, and Class2 do not need to be prepended with a FQN within the module that imported it. So the "with" syntax eliminates the need for "aliasing" one by one as would be necessary in the "static import" example (It does the aliasing automatically). It removes chances of name conflicts the way aliasing could, but it much simpler manner. We are not renaming namespaces here. Walter has demonstrated this technique before. Furthermore this is just one aspect or use of the syntax. Their were more functionality discussed already. As we pointed out earlier several times, this cuts down on repetition of "lib.module1.special.names" on each alias line. Notice with your import example, you would have to reference the fully qualified name in order to use the symbol in your module. Some may like to do this, but I doubt they would in a large library that pulls in long fully qualified names (also discussed priorly).
It might just be me, but IMHO you're trying to mix apples with oranges; 
either you want fully qualified imports or you want standard imports.  If 
you desperately want to mix them, then I agree with Walter in that aliases 
should be just fine; anyone with half a brain will put them right near the 
import where they can be seen; anyone who doesn't do that is just a bad 
coder.

Whoever said that a programmer would want to separate the alias and import? Are you making up a straw men to pull down? Postion of alias has nothing to do with what we are talking about. We are talking about improving the syntax. Contrary to what Walter keeps saying, the two are not identical in what they do. This has pointed out repeatedly in several posts. Nobody is talking about moving aliases all over the code or even necessarily renaming namespaces. That's up to the programmer and remains so even with the new convention. I'm going to assume that the detractors here aren't really understanding each system. Maybe we should post on a wiki somewhere a thorough description of each system before every attempt to describe each is taken out of context. Otherwise, nobody should be concerned about the new syntax since it won't affect those people. So why contribute to the discussion if you don't want it? On the other hand, we are expresing our need and why. And Walter, you particularly seem to be stirring this pot by repeatedly posting misinformation. We have several times demonstrated the difference between the two systems. If you don't understand what we are saying is different, please ask us to clarify rather than adamantly stating in every post that there is *nothing* different between the two. The difference has been clearly demonstrated more than once. You seem to be refusing to admit it. Ameer, I appreciate your input, but if you read over the last posts this has all been covered before. I'm sure you mean well. All opinions are valuable, but I don't think it's helpful to start describing what constitutes a good and bad programmer. While your deprecation has no relation to what we are talking about, the subtelty of your retort is to cast a possible aspersion on anyone not agreeing with Walter. That's not helpful. I want to say one more thing. Not everyone here contributing to this discussion are contributers to D (Ameer, I'm not addressing this to you). It's really frustrating to have people throw in an opinion when they have not demonstrated a consistant use of D in larger projects or commited any length of time pushing D to its limits. Several dedicated people here are making these import suggestions based on lots of time and experience putting D to use in large projects. It becomes more evident, in that context, why D is NOT the same as Java, C#, C++, and why it shouldn't be the same, even in the context of namespaces. It's a complete mistake to try to cast D in the same mold as those languages, whatever Walter keeps saying. D maintains a different aura and seems to invite a new style, all evidence of a healthy evolution of a language. Fixing the namespace issues that crop up with use, and doing it, let me repeat, elegantly is very important to promoting D's success in larger projects. Please remember, if people here are saying there's no issue and yet have not worked with D in large libraries or projects, I'm afraid I don't see how their opinion can be a substantial demonstration of evidence. I've written way more than I should on this topic and it's beginning to wear on me from having to repeat the same arguments over and over. I'd be best to step out now and let things take the course. But I'm assuming the course will continue to be a limiting one from the direction I see the comments from Walter and others going. Nonetheless... all the best to everyone. -JJR
Jul 10 2006
next sibling parent rko <rko_member pathlink.com> writes:
In article <e8v83l$jfo$1 digitaldaemon.com>, John Reimer says...
In article <e8urqt$2vb2$1 digitaldaemon.com>, Ameer Armaly says...
I've been hearing everyone toss around ideas concerning how to selectively 
import symbols from a module, and how to fqn import a module, and I've 
seriously been wondering: why selectively import at all?  Assuming we get 
static import (maybe not with that keyword, but you get the point), what's 
the need for selectively importing if we can just say:

import std.stdio; // I want writefln!
static import cool.module; //Has a toString function for a special type.
static import std.string; //But most of the time I'll be converting ints and 
such to strings, so I shouldn't have to specify.

There is a reason (I think repeated several times by now) why selective imports are useful: # with lib.module1.special.names # import func1, Struct1, Class2; The above func1, Struct1, and Class2 do not need to be prepended with a FQN within the module that imported it. So the "with" syntax eliminates the need for "aliasing" one by one as would be necessary in the "static import" example (It does the aliasing automatically). It removes chances of name conflicts the way aliasing could, but it much simpler manner. We are not renaming namespaces here. Walter has demonstrated this technique before. Furthermore this is just one aspect or use of the syntax. Their were more functionality discussed already.

that would be neat. why not do it as it is/was in iso modula-2? from lib.module1.special.names import func1, Struct1, Class2; //(http://www.arjay.bc.ca/Modula-2/Text/index.html)
As we pointed out earlier several times, this cuts down on repetition of
"lib.module1.special.names" on each alias line.  Notice with your import
example, you would have to reference the fully qualified name in order to use
the symbol in your module.  Some may like to do this, but I doubt they would in
a large library that pulls in long fully qualified names (also discussed
priorly).

It might just be me, but IMHO you're trying to mix apples with oranges; 
either you want fully qualified imports or you want standard imports.  If 
you desperately want to mix them, then I agree with Walter in that aliases 
should be just fine; anyone with half a brain will put them right near the 
import where they can be seen; anyone who doesn't do that is just a bad 
coder.

Whoever said that a programmer would want to separate the alias and import? Are you making up a straw men to pull down? Postion of alias has nothing to do with what we are talking about. We are talking about improving the syntax. Contrary to what Walter keeps saying, the two are not identical in what they do. This has pointed out repeatedly in several posts. Nobody is talking about moving aliases all over the code or even necessarily renaming namespaces. That's up to the programmer and remains so even with the new convention. I'm going to assume that the detractors here aren't really understanding each system. Maybe we should post on a wiki somewhere a thorough description of each system before every attempt to describe each is taken out of context. Otherwise, nobody should be concerned about the new syntax since it won't affect those people. So why contribute to the discussion if you don't want it? On the other hand, we are expresing our need and why. And Walter, you particularly seem to be stirring this pot by repeatedly posting misinformation. We have several times demonstrated the difference between the two systems. If you don't understand what we are saying is different, please ask us to clarify rather than adamantly stating in every post that there is *nothing* different between the two. The difference has been clearly demonstrated more than once. You seem to be refusing to admit it. Ameer, I appreciate your input, but if you read over the last posts this has all been covered before. I'm sure you mean well. All opinions are valuable, but I don't think it's helpful to start describing what constitutes a good and bad programmer. While your deprecation has no relation to what we are talking about, the subtelty of your retort is to cast a possible aspersion on anyone not agreeing with Walter. That's not helpful. I want to say one more thing. Not everyone here contributing to this discussion are contributers to D (Ameer, I'm not addressing this to you). It's really frustrating to have people throw in an opinion when they have not demonstrated a consistant use of D in larger projects or commited any length of time pushing D to its limits. Several dedicated people here are making these import suggestions based on lots of time and experience putting D to use in large projects. It becomes more evident, in that context, why D is NOT the same as Java, C#, C++, and why it shouldn't be the same, even in the context of namespaces. It's a complete mistake to try to cast D in the same mold as those languages, whatever Walter keeps saying. D maintains a different aura and seems to invite a new style, all evidence of a healthy evolution of a language. Fixing the namespace issues that crop up with use, and doing it, let me repeat, elegantly is very important to promoting D's success in larger projects. Please remember, if people here are saying there's no issue and yet have not worked with D in large libraries or projects, I'm afraid I don't see how their opinion can be a substantial demonstration of evidence. I've written way more than I should on this topic and it's beginning to wear on me from having to repeat the same arguments over and over. I'd be best to step out now and let things take the course. But I'm assuming the course will continue to be a limiting one from the direction I see the comments from Walter and others going. Nonetheless... all the best to everyone. -JJR

rko
Jul 10 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:
 And Walter, you particularly seem to be stirring this pot by repeatedly posting
 misinformation.  We have several times demonstrated the difference between the
 two systems.  If you don't understand what we are saying is different, please
 ask us to clarify rather than adamantly stating in every post that there is
 *nothing* different between the two.  The difference has been clearly
 demonstrated more than once.  You seem to be refusing to admit it.

So I've apparently missed something. Please explain what the semantic difference is.
Jul 10 2006
parent reply Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:
 John Reimer wrote:
 And Walter, you particularly seem to be stirring this pot by 
 repeatedly posting
 misinformation.  We have several times demonstrated the difference 
 between the
 two systems.  If you don't understand what we are saying is different, 
 please
 ask us to clarify rather than adamantly stating in every post that 
 there is
 *nothing* different between the two.  The difference has been clearly
 demonstrated more than once.  You seem to be refusing to admit it.

So I've apparently missed something. Please explain what the semantic difference is.

Here's what I've understood: (Using Rioshin's examples) You propose this: static import module.name; alias module.name.foo bar; foo(); // illegal module.name.foo(); // legal bar(); // legal With minor syntax variations, here's what others are proposing: with module.name import foo as bar; foo(); // illegal module.name.foo(); // illegal bar(); // legal Notice how the FQN would be illegal. (That's basically it, right?) ==== Personally, I think both "static import" (or some variation of it), selective import (with .. import ..) and import with aliasing (import .. as ..) are needed. However, I don't like the "as" syntax: I think a symbol would make it easier to read. My preferred choice would be =, but like this: with a.b.c import f1 = foo1, f2 = foo2, f3 = foo3; (Where f1, f2 and f3 are the aliased names.) I think the symbols provide visual stops to understand clearly what's going on. That also makes me dislike: import a.b.c d; Because the space is easy to miss. IMO -- Carlos Santander Bernal
Jul 11 2006
parent Walter Bright <newshound digitalmars.com> writes:
Carlos Santander wrote:
 Here's what I've understood:
 
 (Using Rioshin's examples)
 
 You propose this:
 
     static import module.name;
     alias module.name.foo bar;
 
     foo();    // illegal
     module.name.foo();    // legal
     bar();    // legal
 
 With minor syntax variations, here's what others are proposing:
 
     with module.name import foo as bar;
 
     foo();    // illegal
     module.name.foo();    // illegal
     bar();    // legal
 
 Notice how the FQN would be illegal.
 
 (That's basically it, right?)

Yes, but I don't think it is a substantive difference.
 ====
 
 Personally, I think both "static import" (or some variation of it), 
 selective import (with .. import ..) and import with aliasing (import .. 
 as ..) are needed. However, I don't like the "as" syntax: I think a 
 symbol would make it easier to read. My preferred choice would be =, but 
 like this:
 
     with a.b.c import f1 = foo1, f2 = foo2, f3 = foo3;
 
 (Where f1, f2 and f3 are the aliased names.) I think the symbols provide 
 visual stops to understand clearly what's going on. That also makes me 
 dislike:
 
     import a.b.c d;
 
 Because the space is easy to miss. IMO

Some good points.
Jul 12 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:
 Several dedicated people here are making these import suggestions based on lots
 of time and experience putting D to use in large projects.  It becomes more
 evident, in that context, why D is NOT the same as Java, C#, C++, and why it
 shouldn't be the same, even in the context of namespaces. It's a complete
 mistake to try to cast D in the same mold as those languages, whatever Walter
 keeps saying.  D maintains a different aura and seems to invite a new style,
all
 evidence of a healthy evolution of a language.

It's easy to demonstrate the utility of feature X if it has a proven track record in other languages. If it does not exist in those other languages, the case for X must have a significantly higher bar to get over. It isn't just me that has to be convinced. D, in order to broaden its audience, must appear to have a solid collection of useful capabilities. If people get the impression that it's a grab bag of not-so-useful features, it will fail. Features that are the best of what are in other major languages are an easy sell. Features that are unique to D are a much harder sell. For example, template mixins are unique to D and are a hard sell. There isn't much of an obvious track record for what they can do. Ddoc exists for other languages, and is a slam dunk. Everyone gets it right away.
Jul 10 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 John Reimer wrote:
 Several dedicated people here are making these import suggestions based
 on lots
 of time and experience putting D to use in large projects.  It becomes
 more evident, in that context, why D is NOT the same as Java, C#, C++,
 and why it shouldn't be the same, even in the context of namespaces. It's
 a complete mistake to try to cast D in the same mold as those languages,
 whatever Walter
 keeps saying.  D maintains a different aura and seems to invite a new
 style, all evidence of a healthy evolution of a language.

It's easy to demonstrate the utility of feature X if it has a proven track record in other languages. If it does not exist in those other languages, the case for X must have a significantly higher bar to get over. It isn't just me that has to be convinced. D, in order to broaden its audience, must appear to have a solid collection of useful capabilities. If people get the impression that it's a grab bag of not-so-useful features, it will fail.

You couldn't be more right. I have been looking into the possibilities for a startup using D as a core technology. This is based on seeing the potential of D, using D and talking to other people using D. However, I am becoming doubtful that this is something I will even try to go through with. If it is something D need, then it is that the continued shaping of the language use the actual experience starting to be contained in the D community. Walter, you seem unable to listen to (or understand) the issues met when developing libraries in D (which is a different thing from porting an application from C++), we are talking 2-3 years of solid experience writing libraries in D, Ant, Kris and others, they _know_ what the problems are, which I belive is much more important knowledge in this respect, than what was done in C++ many years ago. C++ experience don't help much when developing with D, D experience do. You don't want language committees, then for the sake of those actually using D, LISTEN TO THEM! I am not willing to flog a dead horse. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jul 11 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Lars Ivar Igesund wrote:

 You couldn't be more right. I have been looking into the possibilities for
 a startup using D as a core technology. This is based on seeing the
 potential of D, using D and talking to other people using D. However, I am
 becoming doubtful that this is something I will even try to go through
 with. If it is something D need, then it is that the continued shaping of
 the language use the actual experience starting to be contained in the D
 community.
 
 Walter, you seem unable to listen to (or understand) the issues met when
 developing libraries in D (which is a different thing from porting an
 application from C++), we are talking 2-3 years of solid experience
 writing libraries in D, Ant, Kris and others, they _know_ what the
 problems are, which I belive is much more important knowledge in this
 respect, than what was done in C++ many years ago. C++ experience don't
 help much when developing with D, D experience do. You don't want language
 committees, then for the sake of those actually using D, LISTEN TO THEM! I
 am not willing to flog a dead horse.
 

I believe I might have been a bit rash here, but I got somewhat pissed pouring over all the posts for the last few days. I will therefore restate some of my thoughts in a calmer manner: If we for a second ignore the language issues chatted about recently, most people agree that D is missing libraries to be able to really compete with other languages. It is therefore unfathomable to me why you Walter don't actively try to make it easy to create good libraries in D. Libraries that can be made stable, failsafe and predictable. You have said many enough times that D is different enough to need different solutions to problems already solved in other languages. Why is it then that you seemingly refuse to listen to those that have tried to solve these problems in D over the years? Those that have found that the language features in D probably need to be refined to not only make libraries in D possible, but fun to write, fun to use, safe to use and with a predictable usage pattern. Writing a compiler is an impressive feat in my eyes, but AFAICS not the way to get experience writing libraries in D. Here you'll need to listen to those that have. Frankly, all the problems posted on symbol conflicts in phobos itself should have told you that something is amiss and should be fixed. Since I'm getting the impression that the issue might be fixed soon, it is then getting down to how. Reusing words like static and alias (that have nothing to do in this company) is the wrong way, especially when there are tried and tested solutions in languages like Python with a clear and perfectly understandable syntax not confused by unrelated words. Why should something that can be said unamibigiously in one statement have to be divided into several unclear (static this, alias that)? I wholeheartedly stand behind Kris' RFC elsewhere in the NG. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jul 11 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Lars Ivar Igesund wrote:
 I believe I might have been a bit rash here, but I got somewhat pissed
 pouring over all the posts for the last few days. I will therefore restate
 some of my thoughts in a calmer manner:
 
 If we for a second ignore the language issues chatted about recently, most
 people agree that D is missing libraries to be able to really compete with
 other languages. It is therefore unfathomable to me why you Walter don't
 actively try to make it easy to create good libraries in D. Libraries that
 can be made stable, failsafe and predictable. You have said many enough
 times that D is different enough to need different solutions to problems
 already solved in other languages. Why is it then that you seemingly refuse
 to listen to those that have tried to solve these problems in D over the
 years? Those that have found that the language features in D probably need
 to be refined to not only make libraries in D possible, but fun to write,
 fun to use, safe to use and with a predictable usage pattern.

I think you're a bit too harsh on Walter now. In the recent two week or so Walter has fixed many important things like most of the import bugs. The only thing left are: * some people thing that imports should be private by default - changing this would break some old code, but does it matter? (statistically private imports are much more common) * most of the people want an additional safe import syntax that allows importing to a custom namespace. * some general show-stopper bugs The first two of these are luckily easy to fix. We're not far from 1.0. If were not in a hurry, I would like the interface things to be fixed (that double lookup implementation) too before reaching stable. Then D will be perfect for real production level use. -- Jari-Matti
Jul 11 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Jari-Matti Mäkelä wrote:

 Lars Ivar Igesund wrote:
 I believe I might have been a bit rash here, but I got somewhat pissed
 pouring over all the posts for the last few days. I will therefore
 restate some of my thoughts in a calmer manner:
 
 If we for a second ignore the language issues chatted about recently,
 most people agree that D is missing libraries to be able to really
 compete with other languages. It is therefore unfathomable to me why you
 Walter don't actively try to make it easy to create good libraries in D.
 Libraries that can be made stable, failsafe and predictable. You have
 said many enough times that D is different enough to need different
 solutions to problems already solved in other languages. Why is it then
 that you seemingly refuse to listen to those that have tried to solve
 these problems in D over the years? Those that have found that the
 language features in D probably need to be refined to not only make
 libraries in D possible, but fun to write, fun to use, safe to use and
 with a predictable usage pattern.

I think you're a bit too harsh on Walter now. In the recent two week or so Walter has fixed many important things like most of the import bugs. The only thing left are: * some people thing that imports should be private by default - changing this would break some old code, but does it matter? (statistically private imports are much more common) * most of the people want an additional safe import syntax that allows importing to a custom namespace. * some general show-stopper bugs The first two of these are luckily easy to fix. We're not far from 1.0. If were not in a hurry, I would like the interface things to be fixed (that double lookup implementation) too before reaching stable. Then D will be perfect for real production level use.

Ah, maybe I was still too harsh, but I've been around for a while, and we're not talking new issues. That it really is mostly all about easy fixes, don't make it any more sensible to me that they haven't already been made, or why he keep suggesting fixes so cumbersome that noone will use them. -- 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:
 Jari-Matti Mäkelä wrote:
 
 Lars Ivar Igesund wrote:
 I believe I might have been a bit rash here, but I got somewhat pissed
 pouring over all the posts for the last few days. I will therefore
 restate some of my thoughts in a calmer manner:

 If we for a second ignore the language issues chatted about recently,
 most people agree that D is missing libraries to be able to really
 compete with other languages. It is therefore unfathomable to me why you
 Walter don't actively try to make it easy to create good libraries in D.
 Libraries that can be made stable, failsafe and predictable. You have
 said many enough times that D is different enough to need different
 solutions to problems already solved in other languages. Why is it then
 that you seemingly refuse to listen to those that have tried to solve
 these problems in D over the years? Those that have found that the
 language features in D probably need to be refined to not only make
 libraries in D possible, but fun to write, fun to use, safe to use and
 with a predictable usage pattern.

so Walter has fixed many important things like most of the import bugs. The only thing left are: * some people thing that imports should be private by default - changing this would break some old code, but does it matter? (statistically private imports are much more common) * most of the people want an additional safe import syntax that allows importing to a custom namespace. * some general show-stopper bugs The first two of these are luckily easy to fix. We're not far from 1.0. If were not in a hurry, I would like the interface things to be fixed (that double lookup implementation) too before reaching stable. Then D will be perfect for real production level use.

Ah, maybe I was still too harsh, but I've been around for a while, and we're not talking new issues. That it really is mostly all about easy fixes, don't make it any more sensible to me that they haven't already been made, or why he keep suggesting fixes so cumbersome that noone will use them.

That's what it boils down to. import-and-alias(*) in one step (vs. specific symbol import or both) seems relatively easy to implement and any more argument against that alone just seems silly. Then there's the specific symbol import that C# (and Perl and Python) allow. I could see where perhaps this would be tougher to implement but I think is well worth it; given large libraries and long namespaces it can really make code easier to build, debug and maintain. Like Kris though, I'd settle for the first, at least for v1.0. * import std.stdio stdio; // std.stdio imported and aliased as stdio
Jul 12 2006
prev sibling next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 11 Jul 2006 04:06:13 +0000 (UTC), John Reimer  
<John_member pathlink.com> wrote:
 I'm going to assume that the detractors here aren't really understanding  
 each system. Maybe we should post on a wiki somewhere a thorough  
 description of each system before every attempt to describe each is  
 taken out of context.

That was one of my goals when I started a new thread.. Regan
Jul 11 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:
 John Reimer wrote:
 Several dedicated people here are making these import suggestions 
 based on lots
 of time and experience putting D to use in large projects.  It becomes 
 more
 evident, in that context, why D is NOT the same as Java, C#, C++, and 
 why it
 shouldn't be the same, even in the context of namespaces. It's a complete
 mistake to try to cast D in the same mold as those languages, whatever 
 Walter
 keeps saying.  D maintains a different aura and seems to invite a new 
 style, all
 evidence of a healthy evolution of a language.

It's easy to demonstrate the utility of feature X if it has a proven track record in other languages. If it does not exist in those other languages, the case for X must have a significantly higher bar to get over.

Perl's module importing supports subsetting of symbols. use module; -- imports everything in the module use module(sym1,sym2); -- imports strictly sym1 and 2, and nothing else. From a maintainability standpoint, being able to easily and quickly deduce where a symbol comes from is invaluable. More so when a language is highly dynamic as perl is, though it holds for all languages. It's one of the things that bugs me about c and c++.. it's often a pain to discover where some symbol comes from without the use of grep or source indexers (lxr, cscope, c/etags, intellisense and its ilk). This is one of the core aspects of this thread, imho, and it's not been explicitly pointed out (though I could have easily missed it amongst the avalanche of posts). Later, Brad
Jul 11 2006