digitalmars.D.bugs - import bug - severe
- Ant (33/33) May 29 2004 linux DMD 0.91
- Ant (7/10) May 30 2004 [...]
- Walter (5/35) May 30 2004 What's happening is the toString in the import is found before the toStr...
- Ant (16/19) May 30 2004 thanks, but I can still se a bug there:
- Walter (8/27) May 30 2004 toString
- Ant (8/35) May 30 2004 name lookup? I care about the signature of the function/method.
- Walter (5/12) May 30 2004 The idea of name lookup happening, *then* overload resolution, operates ...
- Ivan Senji (15/27) May 31 2004 the
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
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...toStringWhat's happening is the toString in the import is found before theBut std.string.toString does exist (name lookup is done before overload resolution).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)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...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?In article <c9dbos$jts$1 digitaldaemon.com>, Walter says...toStringWhat's happening is the toString in the import is found before theBut std.string.toString does exist (name lookup is done before overload resolution).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.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
"Ant" <Ant_member pathlink.com> wrote in message news:c9dn2p$1321$1 digitaldaemon.com...In article <c9djvh$urc$1 digitaldaemon.com>, Walter says...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.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?
May 30 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...theIn article <c9djvh$urc$1 digitaldaemon.com>, Walter says...The idea of name lookup happening, *then* overload resolution, operatesBut 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?same as in C++. It's a chicken-and-egg problem to try to do it based ontypesignatures 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