I think these features to enable catching errors at compile time are necessary.
however I was wondering if there are a few shortcuts.
I'm running into two situations:
first (and simplest)
I have a file ftoa with a single class or function ... lets say char[]
ftoa(real);

in my other file I say
import ftoa;
alias ftoa.ftoa ftoa;
nope! can't do it.  Is there any way I can call it ftoa without having to name
my file different than my function (or especially class as the case may be)

secondly:
it would be nice if I could alias everything in a module;
alias ftoa.* *;
or something :-)
--Daniel


In article <c9ti5d$2vk4$1@digitaldaemon.com>, Walter says...
>
>
>"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c9thhq$2urf$1@digitaldaemon.com...
>> I distictly remember getting a much more misleading error when I experimented with overloads some time ago, though. Was there a related compiler error in earlier DMD versions?
>
>That's possible. I don't remember.
>
>> > There is an ambiguity, and the compiler issues an error for it. The
>reason
>> > it behaves this way is to avoid the C++ global namespace pollution
>problem,
>> > where two completely unrelated functions in two unrelated source files happen to have the same name, and inadvertantly overload against each
>other
>> > causing some very strange errors.
>> What kind of strange errors are these? It seems to me that overloads with different argument types are unproblematic. You can sometimes have ambiguous calls, for example, if one function takes the base class type the other function's parameter but that'd simply cause a compiler error. Nothing that I would call "strange".
>
>Suppose, in file 'a.h', you have:
>    void output(int);
>    void output(long);
>which sends its argument to stdout. You download 'b.h' off the net, which has:
>    void output(char);
>buried in it somewhere which writes its argument out to the serial port. Now,
>    #include "a.h"
>    output('c');
>and all is fine. Now,
>   #include "a.h"
>    #include "b.h"
>    output('c');
>and your program breaks at runtime, possibly in invisible ways.
>
>In D, this would break in an obvious manner at compile time. Much more reliable.
>
>

Walter wrote:
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> news:c9thhq$2urf$1@digitaldaemon.com...
> 
>>I distictly remember getting a much more misleading error when I
>>experimented with overloads some time ago, though. Was there a related
>>compiler error in earlier DMD versions?
> 
> 
> That's possible. I don't remember.
> 
> 
>>>There is an ambiguity, and the compiler issues an error for it. The
> 
> reason
> 
>>>it behaves this way is to avoid the C++ global namespace pollution
> 
> problem,
> 
>>>where two completely unrelated functions in two unrelated source files
>>>happen to have the same name, and inadvertantly overload against each
> 
> other
> 
>>>causing some very strange errors.
>>
>>What kind of strange errors are these? It seems to me that overloads
>>with different argument types are unproblematic. You can sometimes have
>>ambiguous calls, for example, if one function takes the base class type
>>the other function's parameter but that'd simply cause a compiler error.
>>Nothing that I would call "strange".
> 
> 
> Suppose, in file 'a.h', you have:
>     void output(int);
>     void output(long);
> which sends its argument to stdout. You download 'b.h' off the net, which
> has:
>     void output(char);
> buried in it somewhere which writes its argument out to the serial port.
> Now,
>     #include "a.h"
>     output('c');
> and all is fine. Now,
>    #include "a.h"
>     #include "b.h"
>     output('c');
> and your program breaks at runtime, possibly in invisible ways.

Heh, the other reason being the implicit conversion between char and int, of course (hint,hint) ;).

But I get your point. Thanks for the example.


Hauke

<hellcatv@hotmail.com> wrote in message news:c9tjiv$3e$1@digitaldaemon.com...
> I think these features to enable catching errors at compile time are
necessary.
> however I was wondering if there are a few shortcuts.
> I'm running into two situations:
> first (and simplest)
> I have a file ftoa with a single class or function ... lets say char[]
> ftoa(real);
>
> in my other file I say
> import ftoa;
> alias ftoa.ftoa ftoa;
> nope! can't do it.
> Is there any way I can call it ftoa without having to name
> my file different than my function (or especially class as the case may
be)

There's no way to distinguish the names if you don't name them something different.

> secondly:
> it would be nice if I could alias everything in a module;
> alias ftoa.* *;
> or something :-)

Seems a little too easy <g>.

"Walter" <newshound@digitalmars.com> escribió en el mensaje
news:c9tf74$2rrl$1@digitaldaemon.com
| The error message I get is:
| unichar.d(2): function isSeparator conflicts with funkyMenu.isSeparator at
| funkyMenu.d(3)
|

I believe there's a problem with this message. Suppose you're compiling a whole bunch of files and you get messages like this one (like what happened to me trying to compile mango beta 7), how could you possibly know where the conflict is? It should rather say something like "myApp.d(9): do you mean unichar.isSeparator or funkyMenu.isSeparator?".

-----------------------
Carlos Santander Bernal

In article <c9tghe$2tec$1@digitaldaemon.com>, Sean Kelly wrote:
> Hauke Duden wrote:
> >
>> In C++ there'd be no such problem because the call is not actually ambiguous! It is perfectly clear that the MenuItem version is the one that should be called.
>> 
>> That's what I mean and that's the reason why I don't want to define any global functions with names that may also occur in other contexts. Otherwise there may be weird effects for the library's user like working code failing to compile once another import is added - even though there is no ambiguity.
> 
> I prefer to think of modules as C++ namespaces.  And in C++ I rarely import symbols with a "using" declaration, but rather fully qualify them: std::cout, etc.  So why not the same thing here?  unichar.toLower, etc.  Or come up with a shorter module name if that one is too long.

In C++, that's a good habit.

But in D you don't have to, because the potential conflicts between modules/namespaces will be detected automatically by the compiler.

In short: If you want to be absolutely sure, C++ forces you to specify everything. In D you can use unqualified names as much as you like, and only when it is necessary to resolve the conflict you have to fully qualify them. Productive (because you're not likely to bump into a conflict too often) and safe (no surprises when you do).

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

Carlos Santander B. wrote:
> "Walter" <newshound@digitalmars.com> escribió en el mensaje
> news:c9tf74$2rrl$1@digitaldaemon.com
> | The error message I get is:
> | unichar.d(2): function isSeparator conflicts with funkyMenu.isSeparator at
> | funkyMenu.d(3)
> |
> 
> I believe there's a problem with this message. Suppose you're compiling a
> whole bunch of files and you get messages like this one (like what happened
> to me trying to compile mango beta 7), how could you possibly know where the
> conflict is? It should rather say something like "myApp.d(9): do you mean
> unichar.isSeparator or funkyMenu.isSeparator?".

Yes, in fact I think it'd be ideal to provide the 3 locations involved: caller and 2 definitions...

myApp.d(9): ambiguous "isSeparator" = unichar.d(946) or funkyMenu.d(86).

This could be tremendously helpful! As libraries get more complicated, these issues get harder and harder for the code maintainer to track down.


> 
> -----------------------
> Carlos Santander Bernal




-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/