Thread overview
import bug - severe
May 30, 2004
Ant
May 30, 2004
Ant
May 30, 2004
Walter
May 30, 2004
Ant
May 30, 2004
Walter
May 30, 2004
Ant
May 31, 2004
Walter
May 31, 2004
Ivan Senji
May 30, 2004
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
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
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
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
"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
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 31, 2004
"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 31, 2004
"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.