What I did temporarily was just remove the SuperStricts in all the other files and fortunatly there was only 5 or 6 classes, but imagine on a larger project where you have like 40 files, it would be a load of stupid work.
But if you must reference like that, why not create a base type that they both extend...
Thats not a bad idea, but my ships are triangles and missiles are dots, so I'm not sure how I can make an abtract class that can handle any kind of collision, but anyway there are other dependencies. Such as each TPlayer has references to the TShip and TMissiles that belong to it. So I'm still at my original problem.
Yes. But what's that got to do with cyclic imports?
How would that work anyway? How would you compile something that depends on something else (that isn't compiled, because it's waiting for the other bit to be compiled first) being compiled?
Its just not possible.
Not even GCC, the underlaying compiler for the C / C++ part does support it as even C / C++ does not allow cyclic imports!
Java has this capability and I use it all the time. In Java class Ship could import class Missile and class Missile could import class Ship.
I think way imports work should be changed so that cyclic imports are available. If I'm right in what I thought .i files are for, couldn't you just generate the .i files for any .bmx file being used in compilation, then, since each .bmx file has the information about every other .bmx file, you can run the compiler proper on the .bmx files to generate the respective assembly files. And there you go. TShip knows about TMissile and TMissile knows about TShip.
But if you must reference like that, why not create a base type that they both extend...
Thats not a bad idea, but my ships are triangles and missiles are dots, so I'm not sure how I can make an abtract class that can handle any kind of collision, but anyway there are other dependencies. Such as each TPlayer has references to the TShip and TMissiles that belong to it. So I'm still at my original problem.
Yes. But what's that got to do with cyclic imports?
How would that work anyway? How would you compile something that depends on something else (that isn't compiled, because it's waiting for the other bit to be compiled first) being compiled?
Its just not possible.
Not even GCC, the underlaying compiler for the C / C++ part does support it as even C / C++ does not allow cyclic imports!
Java has this capability and I use it all the time. In Java class Ship could import class Missile and class Missile could import class Ship.
I think way imports work should be changed so that cyclic imports are available. If I'm right in what I thought .i files are for, couldn't you just generate the .i files for any .bmx file being used in compilation, then, since each .bmx file has the information about every other .bmx file, you can run the compiler proper on the .bmx files to generate the respective assembly files. And there you go. TShip knows about TMissile and TMissile knows about TShip.