www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - import bug - severe

reply Ant <duitoolkit yahoo.ca> writes:
linux DMD 0.91

this use to compile but no longer.


//private import std.string; // if the import is here it works
class MyObject
{
	
	private import std.string; // if removed :: OK

	this()
	{
		printf("%.*s\n", toString());
		// the bad sintax version works!
		// printf("%.*s\n", Object.toString()); // this version works!
		// printf("%.*s\n", MyObject.toString()); // this doesn't!
	}
}

int main(char[][] args)
{
	
	MyObject mo = new MyObject();
	
	return 0;
}

I bet it's trying to use toString from std.string
i.e. is using std.string like a mixin(?!)


I sincerely hope this is a bug! please don't tell me otherwise!

DUI and leds don't compile with 0.91

(I don't think I tried with .90 or .89
I'm still concerned with the license
but I relaxed a bit since Matthew confirmed that it's going to change)

Ant
May 29 2004
next sibling parent Ant <duitoolkit yahoo.ca> writes:
On Sun, 30 May 2004 00:32:20 -0400, Ant wrote:

 linux DMD 0.91
 
 this use to compile but no longer.
[...] well, dec 28,03 I asked Walter if it would be supported in the but future he never answered. it was used on phobos. it use to solve the import forward reference problem. Ant
May 30 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
What's happening is the toString in the import is found before the toString
of the base class. That follows the normal lookup rules. (The reason it
didn't find it in earlier versions was a compiler bug.)

"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.05.30.04.32.19.592390 yahoo.ca...
 linux DMD 0.91

 this use to compile but no longer.


 //private import std.string; // if the import is here it works
 class MyObject
 {

 private import std.string; // if removed :: OK

 this()
 {
 printf("%.*s\n", toString());
 // the bad sintax version works!
 // printf("%.*s\n", Object.toString()); // this version works!
 // printf("%.*s\n", MyObject.toString()); // this doesn't!
 }
 }

 int main(char[][] args)
 {

 MyObject mo = new MyObject();

 return 0;
 }

 I bet it's trying to use toString from std.string
 i.e. is using std.string like a mixin(?!)


 I sincerely hope this is a bug! please don't tell me otherwise!

 DUI and leds don't compile with 0.91

 (I don't think I tried with .90 or .89
 I'm still concerned with the license
 but I relaxed a bit since Matthew confirmed that it's going to change)

 Ant
May 30 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <c9dbos$jts$1 digitaldaemon.com>, Walter says...
What's happening is the toString in the import is found before the toString
of the base class. That follows the normal lookup rules. (The reason it
didn't find it in earlier versions was a compiler bug.)
thanks, but I can still se a bug there: class MyObject { private import std.string; this() { printf("%.*s\n", toString()); } } clearly toString() is not the std.string.toString() because that function doesn't exist. however the Object.toString() does exist and it's not found. I'll have to change all of DUI and leds anyways (I'm already afraid of the forward references nightmare again) Ant
May 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:c9dhqc$ru6$1 digitaldaemon.com...
 In article <c9dbos$jts$1 digitaldaemon.com>, Walter says...
What's happening is the toString in the import is found before the
toString
of the base class. That follows the normal lookup rules. (The reason it
didn't find it in earlier versions was a compiler bug.)
thanks, but I can still se a bug there: class MyObject { private import std.string; this() { printf("%.*s\n", toString()); } } clearly toString() is not the std.string.toString() because that function doesn't exist.
But std.string.toString does exist (name lookup is done before overload resolution).
 however the Object.toString() does exist and it's not found.

 I'll have to change all of DUI and leds anyways
 (I'm already afraid of the forward references nightmare again)
D is a bit better than it used to be in resolving forward references. I'd like to help make it better, so when you get blocked with this please post an example.
May 30 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <c9djvh$urc$1 digitaldaemon.com>, Walter says...
"Ant" <Ant_member pathlink.com> wrote in message
news:c9dhqc$ru6$1 digitaldaemon.com...
 In article <c9dbos$jts$1 digitaldaemon.com>, Walter says...
What's happening is the toString in the import is found before the
toString
of the base class. That follows the normal lookup rules. (The reason it
didn't find it in earlier versions was a compiler bug.)
thanks, but I can still se a bug there: class MyObject { private import std.string; this() { printf("%.*s\n", toString()); } } clearly toString() is not the std.string.toString() because that function doesn't exist.
But std.string.toString does exist (name lookup is done before overload resolution).
name lookup? I care about the signature of the function/method. std.string contains several function named "toString" but all acept one parameter Object has a method toString with not parameters should the method with no parameters be used?
D is a bit better than it used to be in resolving forward references. I'd
like to help make it better, so when you get blocked with this please post
an example.
I'll do that. but I'll first try to move to module level only the non OO imports. Ant
May 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:c9dn2p$1321$1 digitaldaemon.com...
 In article <c9djvh$urc$1 digitaldaemon.com>, Walter says...
But std.string.toString does exist (name lookup is done before overload
resolution).
name lookup? I care about the signature of the function/method. std.string contains several function named "toString" but all acept one parameter Object has a method toString with not parameters should the method with no parameters be used?
The idea of name lookup happening, *then* overload resolution, operates the same as in C++. It's a chicken-and-egg problem to try to do it based on type signatures because of implicit conversions.
May 30 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c9echg$206d$1 digitaldaemon.com...
 "Ant" <Ant_member pathlink.com> wrote in message
 news:c9dn2p$1321$1 digitaldaemon.com...
 In article <c9djvh$urc$1 digitaldaemon.com>, Walter says...
But std.string.toString does exist (name lookup is done before overload
resolution).
name lookup? I care about the signature of the function/method. std.string contains several function named "toString" but all acept one parameter Object has a method toString with not parameters should the method with no parameters be used?
The idea of name lookup happening, *then* overload resolution, operates
the
 same as in C++. It's a chicken-and-egg problem to try to do it based on
type
 signatures because of implicit conversions.
This looks like the same problem like the one with operator overloading. For example A has opSub(int) B has opSub_r(A) A a; B b; a - b; doesn't work: the reason: B doesn't mach opSub(int) but if A doesn't have opSub(int) it does work! This is a feature that can cause normal code to break: If i use someones A class and define my own B with opSub(A) and everything works ok, the creator of A can very easilly break my code by adding any opSub operator.
May 31 2004