www.digitalmars.com         C & C++   DMDScript  

D - SWT port

reply Ant <Ant_member pathlink.com> writes:
how it the SWT port going?

I a week or two I'll finish a big project at work
and take a few weeks (2003) vacations. I would like to help.

Beside partial implementation of interfaces on abstract classes
how did you solve the other java->D conversion problems:

- How automatic did you made the conversion?

- library
did you create a lib with String, Vector and other very common
java classes (I would have done so, Walter expressed disagreement)

and mostly I'm curious on how to you do the static initializations
(I don't think is called static initialization, here is the example):
class A
{
   B b = new B();    // illigal in D (right?)
   public A()
   {
      //
   }
}

Ant
Feb 22 2004
next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
Ant,

We welcome the help.  John and I have sporadic time to work on it, and are
using 
it to teach ourselves OO and D.  We are by no means experts, so if we ever get 
anywhere with this, we are going to need some experts to get into our code and 
fix our bonehead mistakes.  I realize that posting some of our progress may 
scare the hell out of some people who may want to use this lib in the future, 
but here goes:

<comments embedded>


Ant wrote:
 how it the SWT port going?

Ugh. John is tweaking the makefile to see if we can get around the forward references (remember those from your earlier posts with Lars?). I'm just trying to get the thing to compile with our Hello World app.
 
 I a week or two I'll finish a big project at work
 and take a few weeks (2003) vacations. I would like to help.

Sweet. Send me an email and I'll get you set up to check out the code from our Subversion server. There's also a forum up and running so we can keep track of our questions and not bother the NG here.
 
 Beside partial implementation of interfaces on abstract classes
 how did you solve the other java->D conversion problems:
 
 - How automatic did you made the conversion?

Beyond doing a find/replace for the following, the conversion has been totally manual: boolean --> bit (could have used aliased bool) String --> char[] SWT --> DWT (mostly consts and exception names) static {} --> commented out instanceof --> marked with TODO: (John may have one of these done in point.d or rectangle.d somewhere, using typeof) array initialization { } --> [ ] listeners --> commented out, waiting for delegates classes as structs --> kept them classes for now, but may convert later. Also, I have only worked on the Win32 port, and we will have a bunch of work using the version() {} construct in D when it comes time to fold in linux (gtk+). John is working on linux some, and I know your preference. I just don't have access to a linux box right now...
 - library
 did you create a lib with String, Vector and other very common
 java classes (I would have done so, Walter expressed disagreement)

We did not choose to make libs/utils with common Java classes (String, Vector), but wanted to port to the D way (i.e. try to go with Walter's thoughts).
 and mostly I'm curious on how to you do the static initializations
 (I don't think is called static initialization, here is the example):
 class A
 {
    B b = new B();    // illigal in D (right?)
    public A()
    {
       //
    }
 }

Not sure what you're getting at here. Maybe you could look at the code when your project is done...
 Ant
 
 

Feb 22 2004
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Brad Anderson wrote:

 
 Ugh.  John is tweaking the makefile to see if we can get around the 
 forward references (remember those from your earlier posts with Lars?).  
 I'm just trying to get the thing to compile with our Hello World app.

Hmm, if you are interested in using A-A-P recipes instead of makefiles, you can do as such: (Assuming you are making a dll, although static libs are made the same way): " :dll {onestep} dswt : sources " The {onestep} argument compiles all the files at once instead of one by one. With dmd, this is both faster and removes many forward reference problems. Sadly, it makes it more troublesome to find some types of errors due to a limitation in dmd. The forward reference problem itself should be possible to remove by using private imports, but since it don't I assume it's a bug (it is IMHO). Lars Ivar Igesund
Feb 22 2004
parent reply John Reimer <jjreimer telus.net> writes:
On Sun, 22 Feb 2004 20:07:13 +0100, Lars Ivar Igesund wrote:

 Brad Anderson wrote:
 
 
 Ugh.  John is tweaking the makefile to see if we can get around the
 forward references (remember those from your earlier posts with Lars?).
 I'm just trying to get the thing to compile with our Hello World app.

Hmm, if you are interested in using A-A-P recipes instead of makefiles, you can do as such: (Assuming you are making a dll, although static libs are made the same way):

We currently have not even considered a dll. The primary goal is to get a static lib built first. A makefile was a way for us to learn about how they were built. It was quite educational :). By all means, if you find an easier, better way, go for it.
 "
 :dll {onestep} dswt : sources
 "
 
 The {onestep} argument compiles all the files at once instead of one by
 one. With dmd, this is both faster and removes many forward reference
 problems. Sadly, it makes it more troublesome to find some types of
 errors due to a limitation in dmd.

We tried single step compile. As you know, this is useless for dealing with the forward references especially in dwt. I'm currently using a combined file build step in the makefile (as originally Brad was to). This eliminated about half of the current forward references; but, because of the significance of interdependence in swt, it could not remove them all. I tried many permutations of file compile order which also didn't make it work (it some situations it did).
 The forward reference problem itself should be possible to remove by
 using private imports, but since it don't I assume it's a bug (it is
 IMHO).

Private imports didn't even fix the issues we had in this situation. They may have improved it a bit, but, believe me, it's bad. I vacillated between frustration with the d compiler and what I decided must be java OOP spaghetti.
 Lars Ivar Igesund

Feb 22 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <pan.2004.02.22.23.02.23.100448 telus.net>, John Reimer says...

Private imports didn't even fix the issues we had in this situation.

It's common believe that the "private" for imports is broken. Did you move the imports to inside the class bodies? (of course leave the super class and interfaces out of the class) That might help (It worked for me) it seems to make scope of the import the same as any member of the class. Ant
Feb 22 2004
parent reply John Reimer <jjreimer telus.net> writes:
 
 
 It's common believe that the "private" for imports is broken.
 
 Did you move the imports to inside the class bodies?
 (of course leave the super class and interfaces out of the class)
 
 That might help (It worked for me)
 it seems to make scope of the
 import the same as any member of the class.
 
 Ant
 

No, I hadn't tried that yet. Though, after reading some of your experiences, I was planning on doing that but fogot. I think Brad tried this already. I'll try it later and see if it helps. Frankly, though, that doesn't seem a very intuitive use of D, unless you can clarify why it works. I won't complain too much if it works, though.
Feb 22 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
In article <c1beon$1t16$1 digitaldaemon.com>, John Reimer says...
 
 
 It's common believe that the "private" for imports is broken.
 
 Did you move the imports to inside the class bodies?
 (of course leave the super class and interfaces out of the class)
 
 That might help (It worked for me)
 it seems to make scope of the
 import the same as any member of the class.
 
 Ant
 

No, I hadn't tried that yet. Though, after reading some of your experiences, I was planning on doing that but fogot. I think Brad tried this already. I'll try it later and see if it helps. Frankly, though, that doesn't seem a very intuitive use of D, unless you can clarify why it works. I won't complain too much if it works, though.

It makes sence to me. If we are going to use the import definition inside the class why declare them outside? I tried to explain how I think it works. It's all speculation. look for a thread where I talk to myself on one post and 2 replies. should have "import" on the subject. (I don't have my new reader here) Ant
Feb 22 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
I did try moving the private import inside the class.  I'm trying to think if
it 
was device.d or display.d, moving graphics.gcdata inside.  That allowed me to 
get farther in the compile.

Ant is right that it makes sense to put the import inside the class if that's 
where you're going to use it.  It's not that way in Java, and it's not that way 
in procedural languages, so it's a matter of getting used to it.

BA

John Reimer wrote:
 It's common believe that the "private" for imports is broken.

 Did you move the imports to inside the class bodies?
 (of course leave the super class and interfaces out of the class)

 That might help (It worked for me)
 it seems to make scope of the
 import the same as any member of the class.

 Ant

No, I hadn't tried that yet. Though, after reading some of your experiences, I was planning on doing that but fogot. I think Brad tried this already. I'll try it later and see if it helps. Frankly, though, that doesn't seem a very intuitive use of D, unless you can clarify why it works. I won't complain too much if it works, though.

Feb 22 2004
parent reply C <dont respond.com> writes:
 Ant is right that it makes sense to put the import inside the class if=

 that's where you're going to use it.  It's not that way in Java, and =

 it's not that way in procedural languages, so it's a matter of getting=

 used to it.

It might make sense, but why does not having them in the class break it = ? = And I think this REALLY needs to be documented, and added as a part of t= he = coding style. C On Sun, 22 Feb 2004 18:50:10 -0600, Brad Anderson <brad sankaty.dot.com>= = wrote:
 I did try moving the private import inside the class.  I'm trying to =

 think if it was device.d or display.d, moving graphics.gcdata inside. =

 That allowed me to get farther in the compile.

 Ant is right that it makes sense to put the import inside the class if=

 that's where you're going to use it.  It's not that way in Java, and =

 it's not that way in procedural languages, so it's a matter of getting=

 used to it.

 BA

 John Reimer wrote:
 It's common believe that the "private" for imports is broken.

 Did you move the imports to inside the class bodies?
 (of course leave the super class and interfaces out of the class)

 That might help (It worked for me)
 it seems to make scope of the
 import the same as any member of the class.

 Ant

No, I hadn't tried that yet. Though, after reading some of your =


 experiences, I was planning on doing that but fogot.

 I think Brad tried this already.  I'll try it later and see if it hel=


 Frankly, though, that doesn't seem a very intuitive use of D, unless =


 you can clarify why it works.  I won't complain too much if it works,=


 though.


-- = Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 22 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
C wrote:
 Ant is right that it makes sense to put the import inside the class if 
 that's where you're going to use it.  It's not that way in Java, and 
 it's not that way in procedural languages, so it's a matter of getting 
 used to it.

It might make sense, but why does not having them in the class break it ? And I think this REALLY needs to be documented, and added as a part of the coding style.

I've convinced (just a gut feeling) this kind of stuff is a compiler bug. But since it only occurs in very complicated situations, it's hard to pare it down to a bug report that Walter will accept. And like John was saying, once I find a work-around I don't feel like complaining as much anymore.
 
 C

-- Justin http://jcc_7.tripod.com/d/
Feb 22 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <c1bjr6$253e$1 digitaldaemon.com>, J C Calvarese says...
C wrote:
 Ant is right that it makes sense to put the import inside the class if 
 that's where you're going to use it.  It's not that way in Java, and 
 it's not that way in procedural languages, so it's a matter of getting 
 used to it.

It might make sense, but why does not having them in the class break it ? And I think this REALLY needs to be documented, and added as a part of the coding style.

I've convinced (just a gut feeling) this kind of stuff is a compiler bug. But since it only occurs in very complicated situations,

No, I have a simple example. (now I know I was really talking to myself on those posts.) Ant
Feb 22 2004
parent reply John Reimer <jjreimer telus.net> writes:
On Mon, 23 Feb 2004 01:36:00 +0000, Ant wrote:

 
 No, I have a simple example.
 
 (now I know I was really talking to myself on those posts.)
 
 Ant

:-D You were, but the monologue was not in vain. I read some of it. I guess nobody was running it that issue at the time.
Feb 22 2004
parent C <dont respond.com> writes:
Hehe same here, I went back and read it when i started having the proble=
m =

;).

C

On Sun, 22 Feb 2004 17:39:50 -0800, John Reimer <jjreimer telus.net> wro=
te:

 On Mon, 23 Feb 2004 01:36:00 +0000, Ant wrote:

 No, I have a simple example.

 (now I know I was really talking to myself on those posts.)

 Ant

:-D You were, but the monologue was not in vain. I read some of it. I guess nobody was running it that issue at the ti=


-- = Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 22 2004
prev sibling next sibling parent John Reimer <jjreimer telus.net> writes:
On Sun, 22 Feb 2004 19:01:13 -0800, C wrote:

 Ant is right that it makes sense to put the import inside the class if
 that's where you're going to use it.  It's not that way in Java, and
 it's not that way in procedural languages, so it's a matter of getting
 used to it.

It might make sense, but why does not having them in the class break it ? And I think this REALLY needs to be documented, and added as a part of the coding style.

Yes, it may make sense that it works that way. But it doesn't make sense that it doesn't work outside of the class, ie. module scope (or perhaps I'm missing something again). We expect that an integer declared in module scope will be available to all interior scopes, right? Import doesn't work that way? That said, I guess I just have learn to treat import like I would other internal variable declarations. It's preferable to import within the most global scope that makes use of the imported items. It's also somewhat foreign to me to see an import statement inside of a class definition. That's likely why I have trouble getting familiar with it. It may be the D way. I'll get used to it. And, yes, Charles is right. This issue appears to be very common and should be a documented method of object oriented D coding style. Thanks, John
Feb 22 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <opr3syobatehmtou localhost>, C says...
 Ant is right that it makes sense to put the import inside the class if
 that's where you're going to use it.  It's not that way in Java, and =
 it's not that way in procedural languages, so it's a matter of getting=
 used to it.

It might make sense, but why does not having them in the class break it =

it's a bug (?)
And I think this REALLY needs to be documented, and added as a part of the
coding style.

At the time I asked Walter if this was really a feature of the language or some overlooked constraint by dmd. I don't remember getting any answer back. It is (was?) used on phobos. Ant
Feb 22 2004
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Ant wrote:
 In article <opr3syobatehmtou localhost>, C says...
 
Ant is right that it makes sense to put the import inside the class if
that's where you're going to use it.  It's not that way in Java, and =
it's not that way in procedural languages, so it's a matter of getting=
used to it.

It might make sense, but why does not having them in the class break it =

it's a bug (?)
And I think this REALLY needs to be documented, and added as a part of the
coding style.

At the time I asked Walter if this was really a feature of the language or some overlooked constraint by dmd. I don't remember getting any answer back. It is (was?) used on phobos. Ant

I know I've posted a minimal example (two or three modules) that show the problem very clearly. Walter did answer once that he agreed that it probably was a problem, but that the solution was a complex one. See Walter's post from 6th of January 2004 with subject 'Re: Private imports -> Forward references' Lars Ivar Igesund
Feb 23 2004
parent reply John Reimer <jjreimer telus.net> writes:
 I know I've posted a minimal example (two or three modules) that show
 the problem very clearly. Walter did answer once that he agreed that it
 probably was a problem, but that the solution was a complex one. See
 Walter's post from 6th of January 2004 with subject 'Re: Private imports
 -> Forward references'
 
 Lars Ivar Igesund

I guess one of the goals of d was to keep the compiler simple. But in the process of keeping it simple, it's dumped a fairly large work load on the programmer. That said, what do other languages do to deal with issues of forward references? I was looking at Modula-3, and in contrast to other Pascal-family languages, you may declare names in almost any order in a module and they remain referenceable without an extra declaration or keyword (FORWARD). But I don't know how it works with intermodule references. The very fact that the d compiler flags forward references makes you think that something could be done about it, no?
Feb 23 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
John Reimer wrote:
I know I've posted a minimal example (two or three modules) that show
the problem very clearly. Walter did answer once that he agreed that it
probably was a problem, but that the solution was a complex one. See
Walter's post from 6th of January 2004 with subject 'Re: Private imports
-> Forward references'

Lars Ivar Igesund

I guess one of the goals of d was to keep the compiler simple. But in the process of keeping it simple, it's dumped a fairly large work load on the programmer. That said, what do other languages do to deal with issues of forward references? I was looking at Modula-3, and in contrast to other Pascal-family languages, you may declare names in almost any order in a module and they remain referenceable without an extra declaration or keyword (FORWARD). But I don't know how it works with intermodule references. The very fact that the d compiler flags forward references makes you think that something could be done about it, no?

Thanks to Lars Ivar's description, I found Walter's post on the subject, D/21203 "I agree it's a problem. I'm not sure what to do about it, but I'll keep it in the bug list until it is properly resolved." He's aware of the problem. He agrees it should be fixed. (Too bad we don't have a bug tracking system to keep track of this information...) -- Justin http://jcc_7.tripod.com/d/
Feb 23 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
J C Calvarese wrote:

 
 Thanks to Lars Ivar's description, I found Walter's post on the subject,
 D/21203
 
 "I agree it's a problem. I'm not sure what to do about it, but I'll keep 
 it in the bug list until it is properly resolved."
 
 He's aware of the problem. He agrees it should be fixed. (Too bad we 
 don't have a bug tracking system to keep track of this information...)

As an ugly, awful hack around the problem, you could write a bunch of dummy interfaces, put them all in the same file, and make sure all rely on each other and not the actual classes that cause the problem. The derived classes that do all the work would have to cast their arguments from this interface to the actual implementation, but at least it would actually work. This should allow files to be compiled one at a time too. -- andy
Feb 23 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:c1e2e8$dvk$1 digitaldaemon.com...
 Thanks to Lars Ivar's description, I found Walter's post on the subject,
 D/21203

 "I agree it's a problem. I'm not sure what to do about it, but I'll keep
 it in the bug list until it is properly resolved."

 He's aware of the problem. He agrees it should be fixed. (Too bad we
 don't have a bug tracking system to keep track of this information...)

The fundamental problem with the compiler here is that a base class must lexically precede the derived class. A class in an import, as far as the compiler is concerned, lexically precedes what follows the import statement. -------- foo ----------- import bar; class base { } -------- bar ----------- import foo; class derived : base { } ------------------------ Compiling with dmc -c foo the compiler sees the import bar, and proceeds to analyze it. bar will use foo.base as a base class, and since it lexically precedes base, the error is issued. This problem in the compiler is fixable, but it will take some doing. The workaround is to try to organize the modules so that base classes do not depend on derived classes, then make sure the definitions of the base classes precede the derived classes.
Feb 28 2004
parent "Kris" <someidiot earthlink.net> writes:
You may also get around some of these problems via judicious use of
interfaces (right Walter?), though that could be a lot of retrofit-work
unless you can automate.

"Walter" <walter digitalmars.com> wrote in message >
 The workaround is to try to organize the modules so that base classes do

 depend on derived classes, then make sure the definitions of the base
 classes precede the derived classes.

Feb 28 2004
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:c1asee$t82$1 digitaldaemon.com...
 (I don't think is called static initialization, here is the example):
 class A
 {
    B b = new B();    // illigal in D (right?)
    public A()
    {
       //
    }
 }

class A { static C c; B b; this() { b = new B(); ... } // for dynamic members static this() { c = new C(); } // for static members }
Feb 22 2004
prev sibling parent reply John Reimer <jjreimer telus.net> writes:
On Sun, 22 Feb 2004 18:29:35 +0000, Ant wrote:

 how it the SWT port going?

Brad is responsible for the majority of what's been done already. I've just been helping out here and there as I can. As Brad mentioned, recently I've been working on a comprehensive make file. There have been major headaches with forward references throughout the dwt code (apparently acceptable in Java), and I've been trying to set up the makefile just so. D is quite intractable when it comes to forward references and file arrangement. It's by far one of the most frustrating and NON-user friendly aspects of the language. I've experimented and found that d doesn't even allow forward references with definitions that appear in the same file. Private imports have only solved a small subset of the problems. Unfortunately a large portion of the classes in SWT are highly interdependent. There are forward references all over the place with inheritance and aggregates.
 I a week or two I'll finish a big project at work and take a few weeks
 (2003) vacations. I would like to help.

If the SWT port is of much interest to people, we desperately need experienced developers to help work on DWT. Your experience with DUI will be particularly invaluable because of all the troubleshooting you've done on similar issues already. Even if nobody was really interested in this project, Brad and I decided that we would just continue on as best we could, and learn as we go. We figured we just won't advertise our work to get hopes up unnecessarily. If we get more help, it may actually turn into something useful to everyone.
 Beside partial implementation of interfaces on abstract classes how did
 you solve the other java->D conversion problems:

To be honest, our primary goal was just getting things to compile. We dealt very little with the actual details of the conversion although in some places the changes necessary were obvious and necessary. Some interfaces and abstract classes should be easily converted. Some may be trouble. I certainly underestimated the difficulty of the project even though there are plenty of similarities to D in the Java code.
 - How automatic did you made the conversion?

No automation currently. It's all done by hand.
 - library
 did you create a lib with String, Vector and other very common java
 classes (I would have done so, Walter expressed disagreement)

We have a template string class that's been borrowed from another project (I believe by Christopher Miller). It was to take the place of the Java String class. It doesn't work flawlessly in all instances. There are some significant conflicts that I've noticed. As for other java utility classes, they should be replaceable with d designed ones. That's one of the lesser issues, I think. We just need consensus on what to do here.
 and mostly I'm curious on how to you do the static initializations (I
 don't think is called static initialization, here is the example): class
 A
 {
    B b = new B();    // illigal in D (right?) public A() {
       //
    }
 }

We haven't worried about such issues unless they show up as dmd compile errors. Valid or not, our technique has been to try to get as much compiled as possible, and deal with errors as they show up in the compile process. There are likely plenty of logic/conversion errors undiagnosed as a result. Some are obvious. Some are subtle. So far, the issue you describe above has not really surfaced. Later, John
Feb 22 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
John Reimer wrote:
 If the SWT port is of much interest to people, we desperately need
 experienced developers to help work on DWT.  Your experience with DUI will
 be particularly invaluable because of all the troubleshooting you've done
 on similar issues already.  Even if nobody was really interested in this
 project, Brad and I decided that we would just continue on as best we
 could, and learn as we go.  We figured we just won't advertise our work to
 get hopes up unnecessarily.  If we get more help, it may actually turn
 into something useful to everyone.

Is there someplace I can download a snapshot? I wouldn't mind taking a crack at it.
- How automatic did you made the conversion?

No automation currently. It's all done by hand.

eek. sed is awesome. -- andy
Feb 22 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
 
 Is there someplace I can download a snapshot?  I wouldn't mind taking a 
 crack at it.

Talk to Brad. He's the one maintaining the project files. I just sent him my changes earlier today.
 - How automatic did you made the conversion?

No automation currently. It's all done by hand.

eek. sed is awesome.

Our handle of advanced tools is not our forte yet. We started the project to learn, even if it is the hard way ;-). Later, John
Feb 22 2004
prev sibling parent reply C <dont respond.com> writes:
Hey andy the link to dbfth is broken do you have a url ?  Those delegate=
s =

are cool i didnt know you could use them like that, seemingly anonymous,=
 =

almost lambda like! ( this from a person who doesnt know crap about =

functional )

C

On Sun, 22 Feb 2004 14:57:48 -0800, Andy Friesen <andy ikagames.com> wro=
te:

 John Reimer wrote:
 If the SWT port is of much interest to people, we desperately need
 experienced developers to help work on DWT.  Your experience with DUI=


 will
 be particularly invaluable because of all the troubleshooting you've =


 done
 on similar issues already.  Even if nobody was really interested in t=


 project, Brad and I decided that we would just continue on as best we=


 could, and learn as we go.  We figured we just won't advertise our wo=


 to
 get hopes up unnecessarily.  If we get more help, it may actually tur=


 into something useful to everyone.

Is there someplace I can download a snapshot? I wouldn't mind taking =

 crack at it.

 - How automatic did you made the conversion?

No automation currently. It's all done by hand.

eek. sed is awesome. -- andy

-- = Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 22 2004
parent Andy Friesen <andy ikagames.com> writes:
C wrote:
 Hey andy the link to dbfth is broken do you have a url ?  Those 
 delegates are cool i didnt know you could use them like that, seemingly 
 anonymous, almost lambda like! ( this from a person who doesnt know crap 
 about functional )

Whoops! The link is fixed now. <http://ikagames.com/andy/d/dfbth-19-jan-2004.zip> -- andy
Feb 22 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"John Reimer" <jjreimer telus.net> wrote in message
news:pan.2004.02.22.22.45.28.389403 telus.net...
 As Brad mentioned, recently I've been working on a comprehensive make
 file.  There have been major headaches with forward references throughout
 the dwt code (apparently acceptable in Java), and I've been trying to set
 up the makefile just so. D is quite intractable when it comes to forward
 references and file arrangement. It's by far one of the most frustrating
 and NON-user friendly aspects of the language.  I've experimented and
 found that d doesn't even allow forward references with definitions that
 appear in the same file.  Private imports have only solved a small subset
 of the problems.  Unfortunately a large portion of the classes in SWT are
 highly interdependent.  There are forward references all over the place
 with inheritance and aggregates.

Can you reduce these problems to a small set of canonical examples? This will enable me to work to try to correct any deficiencies in the compiler.
Feb 27 2004
parent John Reimer <jjreimer telus.net> writes:
Walter wrote:
 "John Reimer" <jjreimer telus.net> wrote in message
 news:pan.2004.02.22.22.45.28.389403 telus.net...
 
As Brad mentioned, recently I've been working on a comprehensive make
file.  There have been major headaches with forward references throughout
the dwt code (apparently acceptable in Java), and I've been trying to set
up the makefile just so. D is quite intractable when it comes to forward
references and file arrangement. It's by far one of the most frustrating
and NON-user friendly aspects of the language.  I've experimented and
found that d doesn't even allow forward references with definitions that
appear in the same file.  Private imports have only solved a small subset
of the problems.  Unfortunately a large portion of the classes in SWT are
highly interdependent.  There are forward references all over the place
with inheritance and aggregates.

Can you reduce these problems to a small set of canonical examples? This will enable me to work to try to correct any deficiencies in the compiler.

I could try. It's a complicated mess, and I'm not quite sure how to reduce it to a smaller case because of multiple levels of references. One attempt at reducing the problem into small sample files actual caused the error message to disappear (that mixed with file compile order on the command line; if the files were compiled in one multiple file order, the compiler complained of forward refences; if you rearranged the compile order just so, the errors disappeared). So it's the interdependencies on a more complicated level that are messing things up. I may still be able to create an moderate entanglement of classes and imports that create the problem. :) If this issue could be fixed, I think it would make life so much easier with d. It appears that there are workarounds such as were mentioned by Ant and Lars, but the workarounds are somewhat laborious to work out. Later, John Reimer
Feb 28 2004