www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Conflicts

reply "Bob W" <nospam aol.com> writes:
After the encounter of a conflicting function in std.date
and std.math (floor function), one other conflict seems
to be the toString function in both, std.string and
std.date.

While the floor function in std.date could easily be made
private or renamed, the conflicting toString functions in
std.date and std.string might be less easy to handle.

My question is - can we expect someday a future D version
where these issues are addressed, or will we always have
to use aliases or type the full path for a range of functions
which share the same name in different library modules?
Feb 21 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bob W wrote:

 After the encounter of a conflicting function in std.date
 and std.math (floor function), one other conflict seems
 to be the toString function in both, std.string and
 std.date.

There's a toString in object.d too, affecting all Objects ?
 My question is - can we expect someday a future D version
 where these issues are addressed, or will we always have
 to use aliases or type the full path for a range of functions
 which share the same name in different library modules?

I wouldn't hold my breath, but it would be a Good Thing... Even if the D language itself allows functions with the same name in different modules, one would expect at least the basic library to be without *too* many such conflicts ? In the meantime, we get to type out the full function names. Here's one that I ran into:
 import std.stream;
 import std.stdio;
 
 void main()
 {
   stdout.writefln("hello");
 }

variable std.stream.stdout conflicts with std.c.stdio.stdout Another issue is where you overload:
 void test(char[] str) {}
 void test(wchar[] str) {}
 
 void main()
 {
   test("string");
 }

function overload.test overloads void(char[]str) and void(wchar[]str) both match argument list for test It just seems that D prefers conflicts to be handled explicitly, instead of relying on "complicated" rules ? And of course, Phobos still has a few loose ends left... (compiling a list of issues, like this one, probably helps) --anders
Feb 21 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 21 Feb 2005 13:41:40 +0100, Anders F Björklund <afb algonet.se>  
wrote:
 Bob W wrote:

 After the encounter of a conflicting function in std.date
 and std.math (floor function), one other conflict seems
 to be the toString function in both, std.string and
 std.date.


In this case the conflict is caused by a type alias, d_time is aliased to long, meaning the toString(d_time) in std.date has the same signature as the toString(long) in std.string. Does making the alias a typedef solve it? I think it _should_, as in if it doesn't isn't it a bug.
 There's a toString in object.d too, affecting all Objects ?

I'm not sure it's the same problem, or any problem at all?
 My question is - can we expect someday a future D version
 where these issues are addressed, or will we always have
 to use aliases or type the full path for a range of functions
 which share the same name in different library modules?

I wouldn't hold my breath, but it would be a Good Thing...

Ares is supposed to be the communities effort at solidifying and rectifying areas of phobos, this seems like a perfect candidate for change. So, if/when std.date is added to Ares this issue will be addressed.
 Even if the D language itself allows functions with the
 same name in different modules, one would expect at least
 the basic library to be without *too* many such conflicts ?

Agreed. I think in this case the wrong thing "alias" has been used. Each case is subtlely different.
 In the meantime, we get to type out the full function names.

and/or use aliases.
 Here's one that I ran into:

 import std.stream;
 import std.stdio;
  void main()
 {
   stdout.writefln("hello");
 }

variable std.stream.stdout conflicts with std.c.stdio.stdout

This one is interesting. I think perhaps one is missnamed. eg. std.stream.stdout is a File derived from Stream, so it's a stream. as opposed to std.c.stdio.stdout which is a FILE * maybe rename std.stream.stdout to std.stream.OutStream or something?
 Another issue is where you overload:

 void test(char[] str) {}
 void test(wchar[] str) {}
  void main()
 {
   test("string");
 }

function overload.test overloads void(char[]str) and void(wchar[]str) both match argument list for test It just seems that D prefers conflicts to be handled explicitly, instead of relying on "complicated" rules ?

In some places. In others it uses implicit casts eg. void foo(float b) { printf("%f\n",b); } void main() { long a = 5; foo(a); } compiles, runs, prints "5.000000" :)
 And of course, Phobos still has a few loose ends left...
 (compiling a list of issues, like this one, probably helps)

Definately. Regan
Feb 21 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
 Here's one that I ran into:

 import std.stream;
 import std.stdio;
  void main()
 {
   stdout.writefln("hello");
 }

variable std.stream.stdout conflicts with std.c.stdio.stdout

This one is interesting. I think perhaps one is missnamed. eg. std.stream.stdout is a File derived from Stream, so it's a stream. as opposed to std.c.stdio.stdout which is a FILE * maybe rename std.stream.stdout to std.stream.OutStream or something?

Personally I'm comfortable with the conflict because someone importing both std.stream and std.stdio is asking for two ways to do the same thing so they should have to specify which "stdout" they mean. In fact it is cases like this where D's method of dealing with conflicts works beautifully. We shouldn't change a desirable name just to avoid a conflict.
Feb 21 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 21 Feb 2005 22:29:34 +0000 (UTC), Ben Hinkle  
<Ben_member pathlink.com> wrote:

 Here's one that I ran into:

 import std.stream;
 import std.stdio;
  void main()
 {
   stdout.writefln("hello");
 }

variable std.stream.stdout conflicts with std.c.stdio.stdout

This one is interesting. I think perhaps one is missnamed. eg. std.stream.stdout is a File derived from Stream, so it's a stream. as opposed to std.c.stdio.stdout which is a FILE * maybe rename std.stream.stdout to std.stream.OutStream or something?

Personally I'm comfortable with the conflict because someone importing both std.stream and std.stdio is asking for two ways to do the same thing so they should have to specify which "stdout" they mean.

Sure, but is there a 'better' answer.
 In
 fact it is cases like this where D's method of dealing with conflicts  
 works
 beautifully.

Yeah, but it is 'necessary'.
 We shouldn't
 change a desirable name just to avoid a conflict.

I agree with your statement in general, however: Is stdout really the 'desirable' name for the output stream? C++ used cout, perhaps because they couldn't use stdout, perhaps because it's not actually the "standard output" thing. It seems to me, that it's it's a stream, naming it such tells people what to expect from it. That said, I personally prefer shorter names where possible, so StandardOutputStream would bug me. Regan
Feb 21 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <opsmkl3gpg23k2f5 ally>, Regan Heath says...
On Mon, 21 Feb 2005 22:29:34 +0000 (UTC), Ben Hinkle  
<Ben_member pathlink.com> wrote:

 Here's one that I ran into:

 import std.stream;
 import std.stdio;
  void main()
 {
   stdout.writefln("hello");
 }

variable std.stream.stdout conflicts with std.c.stdio.stdout

This one is interesting. I think perhaps one is missnamed. eg. std.stream.stdout is a File derived from Stream, so it's a stream. as opposed to std.c.stdio.stdout which is a FILE * maybe rename std.stream.stdout to std.stream.OutStream or something?

Personally I'm comfortable with the conflict because someone importing both std.stream and std.stdio is asking for two ways to do the same thing so they should have to specify which "stdout" they mean.

Sure, but is there a 'better' answer.
 In
 fact it is cases like this where D's method of dealing with conflicts  
 works
 beautifully.

Yeah, but it is 'necessary'.
 We shouldn't
 change a desirable name just to avoid a conflict.

I agree with your statement in general, however: Is stdout really the 'desirable' name for the output stream?

You're right that if there is a better name we should switch to it. I can't think of a better name, though.
C++ used cout, perhaps because they couldn't use stdout, perhaps because  
it's not actually the "standard output" thing.

I was wondering the same thing when I was writing my previous post. I'm curious what the history was behind that name. I remember when I first opened up a C++ book and saw "cout" I thought it stood for "C output" and wondered why a book about C++ would talk about C's output stream. :-P Using that faulty guess of mine we could go with "din" and "dout" - though I'm sure the joke would be lost on 99% of the rest of the world.
It seems to me, that it's it's a stream, naming it such tells people what  
to expect from it.
That said, I personally prefer shorter names where possible, so  
StandardOutputStream would bug me.

agreed.
Regan

Feb 21 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 21 Feb 2005 23:49:25 +0000 (UTC), Ben Hinkle  
<Ben_member pathlink.com> wrote:
 In article <opsmkl3gpg23k2f5 ally>, Regan Heath says...
 On Mon, 21 Feb 2005 22:29:34 +0000 (UTC), Ben Hinkle
 <Ben_member pathlink.com> wrote:

 Here's one that I ran into:

 import std.stream;
 import std.stdio;
  void main()
 {
   stdout.writefln("hello");
 }

variable std.stream.stdout conflicts with std.c.stdio.stdout

This one is interesting. I think perhaps one is missnamed. eg. std.stream.stdout is a File derived from Stream, so it's a stream. as opposed to std.c.stdio.stdout which is a FILE * maybe rename std.stream.stdout to std.stream.OutStream or something?

Personally I'm comfortable with the conflict because someone importing both std.stream and std.stdio is asking for two ways to do the same thing so they should have to specify which "stdout" they mean.

Sure, but is there a 'better' answer.
 In
 fact it is cases like this where D's method of dealing with conflicts
 works
 beautifully.

Yeah, but it is 'necessary'.
 We shouldn't
 change a desirable name just to avoid a conflict.

I agree with your statement in general, however: Is stdout really the 'desirable' name for the output stream?

You're right that if there is a better name we should switch to it. I can't think of a better name, though.

More thoughts... Perhaps the new stream is the "standard output", in which case we should rename the old std.c.stdio.stdout to something else. In a perfect world std.c.stdio.stdout wouldn't be included (unless explicitly) because it's the old C interface which we're trying to leave behind, right? Can it be changed so that it's privately imported by std.stdio? (I think that's the culprit tho I've not looked in detail)
 C++ used cout, perhaps because they couldn't use stdout, perhaps because
 it's not actually the "standard output" thing.

I was wondering the same thing when I was writing my previous post. I'm curious what the history was behind that name. I remember when I first opened up a C++ book and saw "cout" I thought it stood for "C output" and wondered why a book about C++ would talk about C's output stream. :-P

I thought that exact same thing. Now I wonder... the 'c' can't possibly stand for 'character' can it?
 Using that faulty guess of mine we could go with "din" and "dout" -  
 though I'm
 sure the joke would be
 lost on 99% of the rest of the world.

Those names are definately short... Regan
Feb 21 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 C++ used cout, perhaps because they couldn't use stdout, perhaps because
 it's not actually the "standard output" thing.

I was wondering the same thing when I was writing my previous post. I'm curious what the history was behind that name. I remember when I first opened up a C++ book and saw "cout" I thought it stood for "C output" and wondered why a book about C++ would talk about C's output stream. :-P

I thought that exact same thing. Now I wonder... the 'c' can't possibly stand for 'character' can it?

"console" is what I hear the most
Feb 21 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 21 Feb 2005 21:14:16 -0500, Ben Hinkle <ben.hinkle gmail.com>  
wrote:

 C++ used cout, perhaps because they couldn't use stdout, perhaps  
 because
 it's not actually the "standard output" thing.

I was wondering the same thing when I was writing my previous post. I'm curious what the history was behind that name. I remember when I first opened up a C++ book and saw "cout" I thought it stood for "C output" and wondered why a book about C++ would talk about C's output stream. :-P

I thought that exact same thing. Now I wonder... the 'c' can't possibly stand for 'character' can it?

"console" is what I hear the most

Duh! of course. Regan
Feb 21 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Regan Heath wrote:
 On Mon, 21 Feb 2005 21:14:16 -0500, Ben Hinkle <ben.hinkle gmail.com>  
 wrote:
 
 C++ used cout, perhaps because they couldn't use stdout, perhaps  
 because
 it's not actually the "standard output" thing.

I was wondering the same thing when I was writing my previous post. I'm curious what the history was behind that name. I remember when I first opened up a C++ book and saw "cout" I thought it stood for "C output" and wondered why a book about C++ would talk about C's output stream. :-P

I thought that exact same thing. Now I wonder... the 'c' can't possibly stand for 'character' can it?

"console" is what I hear the most

Duh! of course. Regan

Reading Stroustrup's the Design and Evolution of C++ does give the following impression: cout like the C stdout, cin like the C stdin, cerr like the C stderr. Where the three are by default attached to the screen, the keyboard and the screen. Those attachments can be changed outside the program at runtime, which gives unbelievable flexibility.
Feb 22 2005
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Anders F Björklund wrote:
[...]
 It just seems that D prefers conflicts to be handled
 explicitly, instead of relying on "complicated" rules ?

I would like D to be more symmetric in this field. The comparable opening of scopes by `with'-statments is treated the other way round: <code> void main() { int i; struct S1{ int i;} S1 s1; struct S2{ int i;} S2 s2; with( s1) with( s2) i=3; printf( "%d %d %d\n", i, s1.i, s2.i); } </code> Here the conflict is resolved by the scope that is opened last. Thereby introducing the possibility of hardly detectable bugs. -manfred
Feb 21 2005