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.


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


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


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;


 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


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.


Why?  Isn't the point of fqn importing to prefix the module name?  This goes 
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.


Why not then just import the whole module in to the namespace?  It's not as 
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.


 Good points.

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


 Why?  Isn't the point of fqn importing to prefix the module name?  This goes 
 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.


 Why not then just import the whole module in to the namespace?  It's not as 
 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:




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

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:




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

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


could't agree more

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

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

 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.


 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.
 


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.


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

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