$ make
bud rdwars \
                -w -op -debug -gc \
                -od.obj \
                -Xstd \
                -L-ldl
map.d(43): enum Direction is forward referenced
make: *** [rdwars] Error 1


PLEASE. I just can't go through ...

Only dmd/phobos + bud should be needed.

Dawid Ciężarkiewicz wrote:
> $ make
> bud rdwars \
>                 -w -op -debug -gc \
>                 -od.obj \
>                 -Xstd \
>                 -L-ldl
> map.d(43): enum Direction is forward referenced
> make: *** [rdwars] Error 1
> 
> 
> PLEASE. I just can't go through ...
> 
> Only dmd/phobos + bud should be needed.

moving the enum Direction declaration from map.d to cell/movable.d let's me compile it, but it gives a linker error (dmd v0.169 on Gentoo Linux).

rm

Dawid Ciężarkiewicz wrote:
> $ make
> bud rdwars \
>                 -w -op -debug -gc \
>                 -od.obj \
>                 -Xstd \
>                 -L-ldl
> map.d(43): enum Direction is forward referenced
> make: *** [rdwars] Error 1
> 
> 
> PLEASE. I just can't go through ...
> 
> Only dmd/phobos + bud should be needed.


I fixed it by putting Direction in its own module, 'direction' and importing where necessary. This essentially moves the Direction enum out of an import cycle, which seems to be the root of the problem.
Actually, cyclic imports can cause many sorts of problems and it's generally wise to avoid them altogether

Powodzenia! ;)

Tom S wrote:

> Dawid Ciężarkiewicz wrote:
>> $ make
>> bud rdwars \
>>                 -w -op -debug -gc \
>>                 -od.obj \
>>                 -Xstd \
>>                 -L-ldl
>> map.d(43): enum Direction is forward referenced
>> make: *** [rdwars] Error 1
>> 
>> 
>> PLEASE. I just can't go through ...
>> 
>> Only dmd/phobos + bud should be needed.
> 
> 
> I fixed it by putting Direction in its own module, 'direction' and importing where necessary. This essentially moves the Direction enum out of an import cycle, which seems to be the root of the problem. Actually, cyclic imports can cause many sorts of problems and it's generally wise to avoid them altogether
> 
> Powodzenia! ;)

Well this sucks. How can you people write real programs? If'd be forced to put every enum in it's own file I'll end up with mess and no hair on my head.

I'll do as you told me. But I will not start any new project in D. I'll wait until D is ready. What is the point of having fancy features where simple things are messed up. :/

Dzięki. :) Dalej powinno być z górki ... - oby.

Dawid Ciężarkiewicz wrote:
> Well this sucks. How can you people write real programs? If'd be forced to
> put every enum in it's own file I'll end up with mess and no hair on my
> head.
> 
> I'll do as you told me. But I will not start any new project in D. I'll wait
> until D is ready. What is the point of having fancy features where simple
> things are messed up. :/
> 
> Dzięki. :) Dalej powinno być z górki ... - oby.

Or you could put all your enums in the same file.
I don't think that cyclic dependencies is such a good idea even when it works, if one finds oneself with that I would merge the  modules importing each other together and if the become to big divide the in some way that don't create a cycle.

Dawid Ciężarkiewicz wrote:
> Tom S wrote:
> 
>> Dawid Ciężarkiewicz wrote:
>>> $ make
>>> bud rdwars \
>>>                 -w -op -debug -gc \
>>>                 -od.obj \
>>>                 -Xstd \
>>>                 -L-ldl
>>> map.d(43): enum Direction is forward referenced
>>> make: *** [rdwars] Error 1
>>>
>>>
>>> PLEASE. I just can't go through ...
>>>
>>> Only dmd/phobos + bud should be needed.
>>
>> I fixed it by putting Direction in its own module, 'direction' and importing where necessary. This essentially moves the Direction enum out of an import cycle, which seems to be the root of the problem. Actually, cyclic imports can cause many sorts of problems and it's generally wise to avoid them altogether
>>
>> Powodzenia! ;)
> 
> Well this sucks. How can you people write real programs? If'd be forced to put every enum in it's own file I'll end up with mess and no hair on my head.
> 
> I'll do as you told me. But I will not start any new project in D. I'll wait until D is ready. What is the point of having fancy features where simple things are messed up. :/
> 
> Dzięki. :) Dalej powinno być z górki ... - oby.

cyclic dependencies should work agreed, but I couldn't easily follow the dependencies you created in your program.

even more, all your import are plain imports :-)
you'd better use "private import ..."
that prevents symbols imported in a module for it's internal
implementation to leak through to other modules.

an example:
module A import module B
module B import module C
=> all public definitions in module C are now available in module A
=> the definitions in C are available in B and in A

or:
module A private import module B
module B private import module C
=> only symbols defined in B are available in A
=> C symbols are not available in A
=> you wish C in A, do a new private import I'd say

roel

rm wrote:

> even more, all your import are plain imports :-)
> you'd better use "private import ..."
> that prevents symbols imported in a module for it's internal
> implementation to leak through to other modules.

Imports are private by default, now.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Lars Ivar Igesund wrote:
> rm wrote:
> 
>> even more, all your import are plain imports :-)
>> you'd better use "private import ..."
>> that prevents symbols imported in a module for it's internal
>> implementation to leak through to other modules.
> 
> Imports are private by default, now.
> 

thx, and making them public?
public import std.stdio; ???

roel

Johan Granberg wrote:
> Or you could put all your enums in the same file.
> I don't think that cyclic dependencies is such a good idea even when it
> works, if one finds oneself with that I would merge the  modules
> importing each other together and if the become to big divide the in
> some way that don't create a cycle.

This is sometimes (quite frequent if you use OOP) just impossible.

You got an parent-object, that holds pointers to many children of different type. And each children have only pointer to it's parent-object to interact with it, and not to each other.

And modules are for humans, not for compilers. It's programmer who should benefit from dividing things into logical parts (by his and only his reasons). I could just put everything in single module ... or event do it using bash, cat and grep. But this is just ... horrible.

In C++ I don't have to think about what is creates cyclic dep. and what does not - I can divide everything into pieces as I like. And I never came to any problems with nesting classes or deps problems. (I just have other terrible problems that C++ features <g>).

I can't understand why D users can live with such bugs and even say "I don't think cyclic deps are good idea" (please don't take it personal :) ). Cyclic deps problems are here for a loooooong time and people seems to be happy when something that helps only notation - like array literals - or only templates is added. And for last three months I just feel like intruder that keep saying "cyclic deps. problem have to be fixed".

While I can live with local notation problems, and without templates making miracles in compile time, I just can't move on with language that forces me to screw up my program logic because of something that throws forward reference errors each time I'm doing anything.

rm wrote:

> Lars Ivar Igesund wrote:
>> rm wrote:
>> 
>>> even more, all your import are plain imports :-)
>>> you'd better use "private import ..."

I tried. Didn't help.

>>> that prevents symbols imported in a module for it's internal implementation to leak through to other modules.
>> 
>> Imports are private by default, now.
>> 
> 
> thx, and making them public?
> public import std.stdio; ???

Using public makes them public. :)

I use public imports almost only when class is derived from other class. Module that want to use new features of child will probably want to use old ones from it's parent.