Import dependency problem
BlitzMax Forums/BlitzMax Beginners Area/Import dependency problem
| ||
| Is this possible? What I want to do is have a Type TConnection that owns a type TProtocol object. Of course, this requires TConnection to know about TProtocol, and so I have to import the TProtocol.bmx file. I'd also like the protocol itself to have a 'pointer' (well a TConnection object that is set to its owner) back to it's owner TConnection object so that it can transfer data back to it without invoking any functions from the TConnection itself. This requires that TProtocol knows about TConnection, though. To summarize TConnection owns a TProtocol object Each TProtocol needs to know about it's owner TConnection object. Is there any way to do this while keeping the files separate? I wish I could just "Declare" TConnection within the TProtocol file, but it doesn't seem there is a way. I tried using extern Type TConnection EndType endextern at the top of the file, just to see, but no luck. Everything else has understandably resulted in a duplicate identifier error. I realize I can alter the design to have the TConnection object handle everything related to it's TProtocol object, but really, the TProtocol object needs to be as autonomous as possible. Given that, I'd prefer not to have to alter the design. Hopefully there's a simple fix that I'm missing. |
| ||
| Oh, and I suppose I could just combine the two types into a single file if I must, but I'd like to keep my source as modular as possible. |
| ||
| good old Include will do the trick. |
| ||
| N/M brainfart. |
| ||
| all include does is insert the code in the included file at that point, so basically its creating one big source file. ;) |
| ||
| [shamed] Darn, I didn't get my edit in fast enough to hide the fact that I didnt' figure that out right away. Thanks much REDi. :) [/shamed] |
| ||
| One drawback to include is that it requires you to strip "strict" out of any file that is being included. It's not a problem yet, but I could see going back and making changes to a non-strict file without realizing that strict isn't there and then getting some mysterious bugs. Is there any way to conditionally include strict that would allow it to remain when the file is being compiled independently? |
| ||
| one call to strict at the top of your main file covers all included files also ;) |
| ||
| And how would you go back to a non script and implement non strict bugs? compilation is done on the large scale and thus the non strict will be found ... if you compile subfiles thought you should think about the "package approach" include all "interlinked" files into 1 bmx and include that bmx into your project ... and never build sources that are part of that package on their own, always only the page. |
| ||
| include all "interlinked" files into 1 bmx and include that bmx into your project ... and never build sources that are part of that package on their own, always only the page. Yeah, that's what I decided to do - make a 'framework' .bmx file and package it all together. It's just, some of the files that are included have no other dependencies - and while not necessary it would be ideal to be able to conditionally (somehow) make them 'strict' when I just want to test some new added code quick. Compiling the whole framework seems like a clunky fix - but it works so meh. All in all, I still much prefer the small taste of blitz that I've had compared to the small taste of C++. :) |
| ||
| How's about : superconnection.bmx Type TSuperConnection Abstract End Type connection.bmx
Import "superconnection.bmx"
Import "protocol.bmx"
Type TConnection Extends TSuperConnection
Field protocol:TProtocol
End Type
protocol.bmx
Import "superconnection.bmx"
Type TProtocol
Field connection:TSuperConnection
End Type
In TSuperConnection you can set up abstract methods etc if you need protocol to call them. This way allows you to remove the need for includes, and makes the code modular, and more importantly, you will only be recompiling the code that changes, rather than recompiling *everything* everytime.... Try to remove "include" from your vocabulary ;-) |
| ||
| Hmm, I'll have to try that. I don't see why it won't work! Thanks Brucey! My source files are still quite small and already the extended compiling was getting on my nerves. |
   |