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

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

> 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?

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/

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

"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.

"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.

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

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.