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=




ps.

 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=


me.




-- =

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,
http://www.digitalmars.com/drn-bin/wwwnews?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,
 http://www.digitalmars.com/drn-bin/wwwnews?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,
 http://www.digitalmars.com/drn-bin/wwwnews?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


not

 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=




his

 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=




rk =


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




n

 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




-- =

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