Again, this misses my point.  You're talking about importing a bunch of stuff whether it's needed or not.  I'm talking about importing something when it's needed, and what ever else is impossible to separate from it at that time.

TZ

"J C Calvarese" <jcc7@cox.net> wrote in message news:d3sp25$vns$1@digitaldaemon.com...
> TechnoZeus wrote:
> > Again, this is a point for implicit imports.  If a person knows what they need to do, and can find a common function that can do it, then it shouldn't matter whether or not they know what module the function is in.  They should simply be able to use it.
> >
> > The only times a module should "need" to be explicitly implied is if it's not in the implicit import list, or if the version that's wanted is in a module other than the one that the implicit import list specifies.  In fact, it would even be possible for implicit importing to be "version" sensative, and not implicitly import a module if the list dpecifies that the called function, object, or whatever, doesn't work in the version specified in the last "version()" statement.
> >
> > TZ
>
> There is absolutely no way that Walter is going to add implicit imports (other than object.d) to D. Here's how I know: many people have asked to allow "import pkg.*" to import all of a directory and he's shown no sign of budging on even that. What you seem to be asking for a hidden "import *" at the beginning of every program. The reason why he hasn't implemented "import pkg.*" isn't because it's hard to implement (I'm fairly certain it'd be quite easy to implement). He hasn't implemented it because he thinks it'd lead to more pesky, weird, and unpredictable bugs in D programs. (FWIW, I think he's right.)
>
> If you really want to have "implicit imports", I think that you can get pretty close using some of D's current functionality (assuming you actually are interesting in using D).
>
> You can create a file (let's call it "all.d") with this content:
>
> public import
> std.array,
> std.asserterror,
> std.base64,
> std.compiler,
> std.conv,
> std.ctype,
> std.date,
> std.dateparse,
> std.file,
> std.format,
> std.gc
> /* etc. */
> ;
>
> (If this sounds like a lot of typing it'd be pretty easy to write a program to search through the file system automatically creating "all.d".)
>
> Then at the beginning of every program you write, you would simply add "import all.d". One line of code at the top of your program shouldn't be too high of a price to achieve nearly implicit importation.
>
> Nonetheless, there's nothing I can do to prevent you from continuing to ask for implicit importing. If you want it, you want it. I'm just not sure what you find appealing about D, since this kind of legerdemain seems antithetical to the D way of thinking. I'm not telling you you're wrong to want to program this way (how you want to program is your decision), but I'm thinking there might be a programming language that is closer to your goals than D is.
>
> -- 
> jcc7
> http://jcc_7.tripod.com/d/

In article <d43cvo$13bd$1@digitaldaemon.com>, TechnoZeus says...
>
>Again, this misses my point.

I understand your point. Perhaps you don't understand mine. I don't expect you to agree with me anyways, so I'll leave it at that.

>You're talking about importing a bunch of stuff whether it's needed or not.  >I'm talking about importing something when it's needed, and what ever else is  impossible to separate from it at that time.
>
>TZ
>
>"J C Calvarese" <jcc7@cox.net> wrote in message news:d3sp25$vns$1@digitaldaemon.com...
>> TechnoZeus wrote:
>> > Again, this is a point for implicit imports.  If a person knows what they need to do, and can find a common function that can do it, then it shouldn't matter whether or not they know what module the function is in.  They should simply be able to use it.
>> >
>> > The only times a module should "need" to be explicitly implied is if it's not in the implicit import list, or if the version that's wanted is in a module other than the one that the implicit import list specifies.  In fact, it would even be possible for implicit importing to be "version" sensative, and not implicitly import a module if the list dpecifies that the called function, object, or whatever, doesn't work in the version specified in the last "version()" statement.
>> >
>> > TZ
>>
>> There is absolutely no way that Walter is going to add implicit imports (other than object.d) to D. Here's how I know: many people have asked to allow "import pkg.*" to import all of a directory and he's shown no sign of budging on even that. What you seem to be asking for a hidden "import *" at the beginning of every program. The reason why he hasn't implemented "import pkg.*" isn't because it's hard to implement (I'm fairly certain it'd be quite easy to implement). He hasn't implemented it because he thinks it'd lead to more pesky, weird, and unpredictable bugs in D programs. (FWIW, I think he's right.)
>>
>> If you really want to have "implicit imports", I think that you can get pretty close using some of D's current functionality (assuming you actually are interesting in using D).
>>
>> You can create a file (let's call it "all.d") with this content:
>>
>> public import
>> std.array,
>> std.asserterror,
>> std.base64,
>> std.compiler,
>> std.conv,
>> std.ctype,
>> std.date,
>> std.dateparse,
>> std.file,
>> std.format,
>> std.gc
>> /* etc. */
>> ;
>>
>> (If this sounds like a lot of typing it'd be pretty easy to write a program to search through the file system automatically creating "all.d".)
>>
>> Then at the beginning of every program you write, you would simply add "import all.d". One line of code at the top of your program shouldn't be too high of a price to achieve nearly implicit importation.
>>
>> Nonetheless, there's nothing I can do to prevent you from continuing to ask for implicit importing. If you want it, you want it. I'm just not sure what you find appealing about D, since this kind of legerdemain seems antithetical to the D way of thinking. I'm not telling you you're wrong to want to program this way (how you want to program is your decision), but I'm thinking there might be a programming language that is closer to your goals than D is.
>>
>> -- 
>> jcc7
>> http://jcc_7.tripod.com/d/

jcc7

J C Calvarese wrote:
> TechnoZeus wrote:
> 
>> Again, this is a point for implicit imports.  If a person knows what they need to do, and can find a common function that can do it, then it shouldn't matter whether or not they know what module the function is in.  They should simply be able to use it.
>>
>> The only times a module should "need" to be explicitly implied is if it's not in the implicit import list, or if the version that's wanted is in a module other than the one that the implicit import list specifies.  In fact, it would even be possible for implicit importing to be "version" sensative, and not implicitly import a module if the list dpecifies that the called function, object, or whatever, doesn't work in the version specified in the last "version()" statement.
>>
>> TZ
> 
> 
> There is absolutely no way that Walter is going to add implicit imports (other than object.d) to D. Here's how I know: many people have asked to allow "import pkg.*" to import all of a directory and he's shown no sign of budging on even that. What you seem to be asking for a hidden "import *" at the beginning of every program. The reason why he hasn't implemented "import pkg.*" isn't because it's hard to implement (I'm fairly certain it'd be quite easy to implement). He hasn't implemented it because he thinks it'd lead to more pesky, weird, and unpredictable bugs in D programs. (FWIW, I think he's right.)
> 
> If you really want to have "implicit imports", I think that you can get pretty close using some of D's current functionality (assuming you actually are interesting in using D).
> 
> You can create a file (let's call it "all.d") with this content:
> 
> public import
> std.array,
> std.asserterror,
> std.base64,
> std.compiler,
> std.conv,
> std.ctype,
> std.date,
> std.dateparse,
> std.file,
> std.format,
> std.gc
> /* etc. */
> ;
> 
> (If this sounds like a lot of typing it'd be pretty easy to write a program to search through the file system automatically creating "all.d".)
> 
> Then at the beginning of every program you write, you would simply add "import all.d". One line of code at the top of your program shouldn't be too high of a price to achieve nearly implicit importation.

Considering this, it might not be that Walter has any reasons of Principle against this -- just that this being this easy to implement, warrants it not being part "of the language".

> Nonetheless, there's nothing I can do to prevent you from continuing to ask for implicit importing. If you want it, you want it. I'm just not sure what you find appealing about D, since this kind of legerdemain seems antithetical to the D way of thinking. I'm not telling you you're wrong to want to program this way (how you want to program is your decision), but I'm thinking there might be a programming language that is closer to your goals than D is.
> 

TechnoZeus wrote:
> Again, this misses my point.  You're talking about importing a bunch
> of stuff whether it's needed or not.  I'm talking about importing
> something when it's needed, and what ever else is impossible to
> separate from it at that time.
> 
> TZ

The origins may be very different, but the end result may be the same.
(IIRC,) in your final binary, only the things that _actually_ get used,
are incorporated. (Please anyone, correct me if I'm wrong here.)

> "J C Calvarese" <jcc7@cox.net> wrote in message
> news:d3sp25$vns$1@digitaldaemon.com...
> 
>> TechnoZeus wrote:
>> 
>>> Again, this is a point for implicit imports.  If a person knows
>>> what they need to do, and can find a common function that can do
>>> it, then it shouldn't matter whether or not they know what module
>>> the function is in.  They should simply be able to use it.
>>> 
>>> The only times a module should "need" to be explicitly implied is
>>> if it's not in the implicit import list, or if the version that's
>>> wanted is in a module other than the one that the implicit import
>>> list specifies.  In fact, it would even be possible for implicit
>>> importing to be "version" sensative, and not implicitly import a
>>> module if the list dpecifies that the called function, object, or
>>> whatever, doesn't work in the version specified in the last
>>> "version()" statement.
>>> 
>>> TZ
>> 
>> There is absolutely no way that Walter is going to add implicit
>> imports (other than object.d) to D. Here's how I know: many people
>> have asked to allow "import pkg.*" to import all of a directory and
>> he's shown no sign of budging on even that. What you seem to be
>> asking for a hidden "import *" at the beginning of every program.
>> The reason why he hasn't implemented "import pkg.*" isn't because
>> it's hard to implement (I'm fairly certain it'd be quite easy to
>> implement). He hasn't implemented it because he thinks it'd lead to
>> more pesky, weird, and unpredictable bugs in D programs. (FWIW, I
>> think he's right.)
>> 
>> If you really want to have "implicit imports", I think that you can
>> get pretty close using some of D's current functionality (assuming
>> you actually are interesting in using D).
>> 
>> You can create a file (let's call it "all.d") with this content:
>> 
>> public import std.array, std.asserterror, std.base64, std.compiler,
>>  std.conv, std.ctype, std.date, std.dateparse, std.file, std.format, std.gc /* etc. */ ;
>> 
>> (If this sounds like a lot of typing it'd be pretty easy to write a
>>  program to search through the file system automatically creating
>> "all.d".)
>> 
>> Then at the beginning of every program you write, you would simply
>> add "import all.d". One line of code at the top of your program
>> shouldn't be too high of a price to achieve nearly implicit
>> importation.
>> 
>> Nonetheless, there's nothing I can do to prevent you from
>> continuing to ask for implicit importing. If you want it, you want
>> it. I'm just not sure what you find appealing about D, since this
>> kind of legerdemain seems antithetical to the D way of thinking.
>> I'm not telling you you're wrong to want to program this way (how
>> you want to program is your decision), but I'm thinking there might
>> be a programming language that is closer to your goals than D is.
>> 
>> -- jcc7 http://jcc_7.tripod.com/d/
> 
> 
> 

You're right... I looked over what you had said, and there is a point in it that I had missed.  Your comparison isn't valid though, because implicit imports would be standardized in the same way as built-in parts of the language are... so there would be no unpredictability.

I'm not talking about importing a bunch of stuff that the programmer doesn't want.  I'm talking about importing standard things that the programmer chooses to use without forcing the programmer to first explicitly tell the compiler where to find them.  The choice to specify an alternative location would still exist, and the choice to explicitly specify the "usual" location would also still exist, but the programmer would be free to let the compiler find the usual things in the usual places automatically if they are used without an explicit import.

Of course, it wouldn't be difficult to make a compiler switch that could turn all implicit importing off, or one that would leave it on but report each instance of it, I would think.  That would be enough to satisfy those who are worried about possibly telling their program to use something that just happens to match a name in the implicit import list but was actually a custom componant that they forgot to include... but even without the compiler set to skip or report implicit imports, they would most likely find that their code wouldn't compile because the implicitly imported item would likely fail to accept the same parameters as their intended custom item.

More to the point, it would be entirely predictable.... but would make D easier to learn and use in a shorter time.  It would also get rid of a huge bug in C and C++ that D has so far inhereted in force... and that is the documentation bug which frequently shows up when someone is so used to something that has become "standard" that they forget it's not "built in" and write about it as if it's a part of the language, when it's not.  Implicit importation of "standard" items would make them effectively part of the language, but without causing code bloat.

TZ

TZ

"J C Calvarese" <jcc7@cox.net> wrote in message news:d43g10$16dh$1@digitaldaemon.com...
> In article <d43cvo$13bd$1@digitaldaemon.com>, TechnoZeus says...
> >
> >Again, this misses my point.
>
> I understand your point. Perhaps you don't understand mine. I don't expect you to agree with me anyways, so I'll leave it at that.
>
> >You're talking about importing a bunch of stuff whether it's needed or not.  >I'm talking about importing something when it's needed, and what ever else is  impossible to separate from it at that time.
> >
> >TZ
> >
> >"J C Calvarese" <jcc7@cox.net> wrote in message news:d3sp25$vns$1@digitaldaemon.com...
> >> TechnoZeus wrote:
> >> > Again, this is a point for implicit imports.  If a person knows what they need to do, and can find a common function that can do it, then it shouldn't matter whether or not they know what module the function is in.  They should simply be able to use it.
> >> >
> >> > The only times a module should "need" to be explicitly implied is if it's not in the implicit import list, or if the version that's wanted is in a module other than the one that the implicit import list specifies.  In fact, it would even be possible for implicit importing to be "version" sensative, and not implicitly import a module if the list dpecifies that the called function, object, or whatever, doesn't work in the version specified in the last "version()" statement.
> >> >
> >> > TZ
> >>
> >> There is absolutely no way that Walter is going to add implicit imports (other than object.d) to D. Here's how I know: many people have asked to allow "import pkg.*" to import all of a directory and he's shown no sign of budging on even that. What you seem to be asking for a hidden "import *" at the beginning of every program. The reason why he hasn't implemented "import pkg.*" isn't because it's hard to implement (I'm fairly certain it'd be quite easy to implement). He hasn't implemented it because he thinks it'd lead to more pesky, weird, and unpredictable bugs in D programs. (FWIW, I think he's right.)
> >>
> >> If you really want to have "implicit imports", I think that you can get pretty close using some of D's current functionality (assuming you actually are interesting in using D).
> >>
> >> You can create a file (let's call it "all.d") with this content:
> >>
> >> public import
> >> std.array,
> >> std.asserterror,
> >> std.base64,
> >> std.compiler,
> >> std.conv,
> >> std.ctype,
> >> std.date,
> >> std.dateparse,
> >> std.file,
> >> std.format,
> >> std.gc
> >> /* etc. */
> >> ;
> >>
> >> (If this sounds like a lot of typing it'd be pretty easy to write a program to search through the file system automatically creating "all.d".)
> >>
> >> Then at the beginning of every program you write, you would simply add "import all.d". One line of code at the top of your program shouldn't be too high of a price to achieve nearly implicit importation.
> >>
> >> Nonetheless, there's nothing I can do to prevent you from continuing to ask for implicit importing. If you want it, you want it. I'm just not sure what you find appealing about D, since this kind of legerdemain seems antithetical to the D way of thinking. I'm not telling you you're wrong to want to program this way (how you want to program is your decision), but I'm thinking there might be a programming language that is closer to your goals than D is.
> >>
> >> -- 
> >> jcc7
> >> http://jcc_7.tripod.com/d/
>
> jcc7