View mode: basic / threaded / horizontal-split · Log in · Help
July 11, 2006
the point of selective importing
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
July 11, 2006
Re: the point of selective importing
"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.
July 11, 2006
Re: the point of selective importing
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.)
July 11, 2006
Re: the point of selective importing
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
July 11, 2006
Re: the point of selective importing
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
July 11, 2006
Re: the point of selective importing
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.
July 11, 2006
Re: the point of selective importing
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.
July 11, 2006
Re: the point of selective importing
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
July 11, 2006
Re: the point of selective importing
"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;
July 11, 2006
Re: the point of selective importing
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
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home