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

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

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

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

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
>
>
could't agree more

rko

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.

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.

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

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

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