www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Angry citizen stikes once again. forward references problems

reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Nested classes, enums and such are unusable if there are any circular
imports. If you have got no luck you get:

   `class X is forward referenced when looking for Y'

error and the only way to have it compile is too change compilation order.
(there was many such posts on D.learn and D.bugs). If you're using dbuild
for that - you can only pray not to hit that problem or not to use nested
things at all.

In extremal situations you can even get something you can't compile in any
way:
http://d.puremagic.com/issues/show_bug.cgi?id=104

This is one of those things that makes me irritated each time I'm dealing
with D, because I use nested logic in classes much. And this is one of
errors that are blockers for DMD 1.0. You can't write serious projects
using D till such errors exists.

I hope that after fixing import conflict problems in 163 (good work BTW) now
has come time to fix other import problems - especially this one. 

Thanks you for your attention.
Jul 30 2006
parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Dawid Ciężarkiewicz wrote:
 In extremal situations you can even get something you can't compile in any
 way:
 http://d.puremagic.com/issues/show_bug.cgi?id=104

I mean: http://d.puremagic.com/issues/show_bug.cgi?id=102 Sorry.
Jul 30 2006
parent reply Derek <derek psyc.ward> writes:
On Sun, 30 Jul 2006 21:55:59 +0200, Dawid Ciężarkiewicz wrote:

 Dawid Ciężarkiewicz wrote:
 In extremal situations you can even get something you can't compile in any
 way:
 http://d.puremagic.com/issues/show_bug.cgi?id=104

I mean: http://d.puremagic.com/issues/show_bug.cgi?id=102

I don't understand this Dawid. It seems you are trying to use a nested class inside another class, and I'm sure you can't and shouldn't do that. I thought the purpose of nested classes was to restrict the scope of the nested class to its parent and thus trying to use it outside of the parent doesn't seem right to me. Your example.. // --- test2.d ----- import test2; class X { Y.NY t; // ?!? But NY is defined as a nested class in Y. static class NX { } } //-------------------------// // --- test.d ----- import test; class Y { X.NX nx; // ?!? But NX is defined as a nested class in X. static class NY { } } //-------------------------// D won't let you do even the more simple case ... //------- test3.d ----- class X { static class NX { } } class Y { NX q; // test3.d(10): identifier 'NX' is not defined } // -------------------- // I think dmd is working correctly, though the error messages are not exactly helpful. -- Derek Parnell Melbourne, Australia "Down with mediocrity!"
Jul 30 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek" <derek psyc.ward> wrote in message 
news:zbzgquaqpewl$.brpiyqr0sclz.dlg 40tude.net...
 I don't understand this Dawid. It seems you are trying to use a nested
 class inside another class, and I'm sure you can't and shouldn't do that.

Why not? What about a parent "factory" class, which needs to create instances of a nested class, which the user can use? The nested class can still access its outer class, and the user can use the nested class instances just fine.
 I thought the purpose of nested classes was to restrict the scope of the
 nested class to its parent and thus trying to use it outside of the parent
 doesn't seem right to me.

Sometimes that's true. Sometimes you just want the nested class to have access to the outer class. Granted, you can do this with friend classes, but.. as mentioned above, if you want an "owner/owned" relationship between the classes, using a nested class seems somewhat more elegant.
 D won't let you do even the more simple case ...

 //------- test3.d -----
 class X
 {
  static class NX
  {
  }
 }

 class Y
 {
     NX q; // test3.d(10): identifier 'NX' is not defined
 }
 // -------------------- //

 I think dmd is working correctly, though the error messages are not 
 exactly
 helpful.

Namespaces, namespaces. Class Y { X.NX q; } And you could even "alias X.NX NX;" if you wanted to. In addition, you'll notice that Walter even added syntax in a recent update to allow you to create instances of nested classes using an outer class reference: X x = new X; X.NX nx = x.new NX; Which seems like you're almost.. well maybe not _encouraged_ but certainly not _blocked from_ creating instances of nested classes outside the owner class.
Jul 30 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Sun, 30 Jul 2006 18:57:14 -0400, Jarrett Billingsley wrote:

 "Derek" <derek psyc.ward> wrote in message 
 news:zbzgquaqpewl$.brpiyqr0sclz.dlg 40tude.net...
 I don't understand this Dawid. It seems you are trying to use a nested
 class inside another class, and I'm sure you can't and shouldn't do that.

Why not? What about a parent "factory" class, which needs to create instances of a nested class, which the user can use? The nested class can still access its outer class, and the user can use the nested class instances just fine.
 I thought the purpose of nested classes was to restrict the scope of the
 nested class to its parent and thus trying to use it outside of the parent
 doesn't seem right to me.

Sometimes that's true. Sometimes you just want the nested class to have access to the outer class. Granted, you can do this with friend classes, but.. as mentioned above, if you want an "owner/owned" relationship between the classes, using a nested class seems somewhat more elegant.

Okay ... but why would you want a nested class to be used as a type inside another class? Seems like a silly thing to do. What's the advantage of doing that?
 D won't let you do even the more simple case ...

 //------- test3.d -----
 class X
 {
  static class NX
  {
  }
 }

 class Y
 {
     NX q; // test3.d(10): identifier 'NX' is not defined
 }
 // -------------------- //

 I think dmd is working correctly, though the error messages are not 
 exactly
 helpful.

Namespaces, namespaces. Class Y { X.NX q; } And you could even "alias X.NX NX;" if you wanted to.

Seems wrong to me. I can't see why one would bother making obscure, hard-to-maintain, hard-to-read classes definitions using this technique. Seems counter-productive. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 31/07/2006 9:46:30 AM
Jul 30 2006
parent kris <foo bar.com> writes:
Derek Parnell wrote:
 On Sun, 30 Jul 2006 18:57:14 -0400, Jarrett Billingsley wrote:
 
 
"Derek" <derek psyc.ward> wrote in message 
news:zbzgquaqpewl$.brpiyqr0sclz.dlg 40tude.net...

I don't understand this Dawid. It seems you are trying to use a nested
class inside another class, and I'm sure you can't and shouldn't do that.

Why not? What about a parent "factory" class, which needs to create instances of a nested class, which the user can use? The nested class can still access its outer class, and the user can use the nested class instances just fine.
I thought the purpose of nested classes was to restrict the scope of the
nested class to its parent and thus trying to use it outside of the parent
doesn't seem right to me.

Sometimes that's true. Sometimes you just want the nested class to have access to the outer class. Granted, you can do this with friend classes, but.. as mentioned above, if you want an "owner/owned" relationship between the classes, using a nested class seems somewhat more elegant.

Okay ... but why would you want a nested class to be used as a type inside another class? Seems like a silly thing to do. What's the advantage of doing that?
D won't let you do even the more simple case ...

//------- test3.d -----
class X
{
 static class NX
 {
 }
}

class Y
{
    NX q; // test3.d(10): identifier 'NX' is not defined
}
// -------------------- //

I think dmd is working correctly, though the error messages are not 
exactly
helpful.

Namespaces, namespaces. Class Y { X.NX q; } And you could even "alias X.NX NX;" if you wanted to.

Seems wrong to me. I can't see why one would bother making obscure, hard-to-maintain, hard-to-read classes definitions using this technique. Seems counter-productive.

Aye ... I'm a big fan of Factory designs, and nested-classes, but would typically not expose the inner class in that manner ~ would be exposed via an interface or something instead. As I understand it, inner-classes (as a concept) are intended primarily as a convenient means of encapsualting specific internal functionality, for either handing off to a framework or for simplifying internal implementation detail. I can't recall reading /any/ papers or documents suggesting they should be made available as general-purpose public classes, and don't recall ever finding a need to do so. Of course, that's just my experience only. Would be very interested to understand why it's needed in this case ...
Jul 30 2006
prev sibling next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Your example is incorrect.  It should be:

class X
{
    static class NX
    {
    }
}

class Y
{
    X.NX q;
}

Which compiles, indeed.

That said, I don't use a lot of cycles as far as nested classes... 
honestly it feels weird to me (as you said.)

So can't... actually you can.  Shouldn't... hmm, yeah.  Gotta love 
conventions, some are good, some are weird.

-[Unknown]


 On Sun, 30 Jul 2006 21:55:59 +0200, Dawid Ciężarkiewicz wrote:
 
 Dawid Ciężarkiewicz wrote:
 In extremal situations you can even get something you can't compile in any
 way:
 http://d.puremagic.com/issues/show_bug.cgi?id=104

http://d.puremagic.com/issues/show_bug.cgi?id=102

I don't understand this Dawid. It seems you are trying to use a nested class inside another class, and I'm sure you can't and shouldn't do that. I thought the purpose of nested classes was to restrict the scope of the nested class to its parent and thus trying to use it outside of the parent doesn't seem right to me. Your example.. // --- test2.d ----- import test2; class X { Y.NY t; // ?!? But NY is defined as a nested class in Y. static class NX { } } //-------------------------// // --- test.d ----- import test; class Y { X.NX nx; // ?!? But NX is defined as a nested class in X. static class NY { } } //-------------------------// D won't let you do even the more simple case ... //------- test3.d ----- class X { static class NX { } } class Y { NX q; // test3.d(10): identifier 'NX' is not defined } // -------------------- // I think dmd is working correctly, though the error messages are not exactly helpful.

Jul 30 2006
prev sibling parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Derek wrote:

 On Sun, 30 Jul 2006 21:55:59 +0200, Dawid Ciężarkiewicz wrote:
 
 Dawid Ciężarkiewicz wrote:
 In extremal situations you can even get something you can't compile in
 any way:
 http://d.puremagic.com/issues/show_bug.cgi?id=104

I mean: http://d.puremagic.com/issues/show_bug.cgi?id=102

I don't understand this Dawid. It seems you are trying to use a nested class inside another class, and I'm sure you can't and shouldn't do that. I thought the purpose of nested classes was to restrict the scope of the nested class to its parent and thus trying to use it outside of the parent doesn't seem right to me.

Not right. Nested _static_ classes are just like all other classes. The only change is just namespace. BTW. I do want use them like that and personally I think it has many advantages. But it's not about classes. It's about symbols used as types. This should make more sense to all unconvinced: $ cat test1.d import test2; class X { Y.NY t; enum NX { BLA, BLA1 } } $ cat test2.d import test1; class Y { X.NX nx; enum NY { FOO, BAR } } Is impossible to compile just like bug #102.
Jul 31 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 31 Jul 2006 09:22:26 +0200, Dawid Ciężarkiewicz wrote:

 Derek wrote:
 
 On Sun, 30 Jul 2006 21:55:59 +0200, Dawid Ciężarkiewicz wrote:
 
 Dawid Ciężarkiewicz wrote:
 In extremal situations you can even get something you can't compile in
 any way:
 http://d.puremagic.com/issues/show_bug.cgi?id=104

I mean: http://d.puremagic.com/issues/show_bug.cgi?id=102

I don't understand this Dawid. It seems you are trying to use a nested class inside another class, and I'm sure you can't and shouldn't do that. I thought the purpose of nested classes was to restrict the scope of the nested class to its parent and thus trying to use it outside of the parent doesn't seem right to me.

Not right. Nested _static_ classes are just like all other classes. The only change is just namespace. BTW. I do want use them like that and personally I think it has many advantages.

Thank you Dawid for helping me to understand your reasoning. I'm still learning things too. However, your response of "Not right." is a bit too restricting. From what you and others have mentioned, it seems that there are at least three purposes of nested classes ... to limit the scope, as a convenience to access parent data members, and to provide a namespace. Of course I can see now that 'static' nesting is just for namespace purposes. However it still seems like a 'hack' to me and the issue of namespaces ought to be better handled by some more explicit mechanism rather than relying on some side-effect of D. But that is an argument for another day <g>.
 But it's not about classes. It's about symbols used as types. This should
 make more sense to all unconvinced:

I was totally aware of the issue with enums etc... as I keep bumping into it too. I just gave up and now use module namespaces for enums. $ cat test1.d import test2; import yenum; class X { yenum.NY t; } $ cat test2.d import test1; import xenum; class Y { xenum.NX nx; } $ cat xenum.d enum NX { BLA, BLA1 } $ cat yenum.d enum NY { FOO, BAR } -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 31/07/2006 5:52:32 PM
Jul 31 2006
parent Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Derek Parnell wrote:
 But it's not about classes. It's about symbols used as types. This should
 make more sense to all unconvinced:

I was totally aware of the issue with enums etc... as I keep bumping into it too. I just gave up and now use module namespaces for enums.

Well - that suck :/ . You and me may live with such limitations. Public will probably hang D on nearby tree and goes back to C++/Java/other languages.
Jul 31 2006