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







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







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).



 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).



 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




 same as in C++. It's a chicken-and-egg problem to try to do it based on




 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