Include and Import
BlitzMax Forums/BlitzMax Beginners Area/Include and Import
| ||
| I was first puzzled over what was the difference between these, but after some quick searching I found out how they are vastly different in how they work. And I also learned how Import is generally a lot better and faster for compile times. Now, for me as I code, I experience being screwed over constantly by Import. I'm sorry Import lovers, I know the fault lies at me, but that doesn't solve the problem. ._. I keep having to compromise and uglify the structure of my source files, which previously had a very nice and easy to understand structure. But now they are one big clustered nonsense of spiderwebs. What I gain in compile time, I lose by tenfolds by simply having to navigate though this mess. Seaching for this problem on the community only gives answers like "yeah, you can include all the types that need each other into one big file and import that". Why should I need to make life harder in order to use a tool that is supposed to make life easier? IT DOESN'T MAKE SENSE. >> But, it doesn't end there. I also keep experiencing other small problems, like constants not applying over an imported source file, but yet, it won't allow me to make new constants in the imported file to make up for it. Despite that it doesn't bother to load the values, it seems well aware that the constant exists, and refuses to let me fix up the problem that it has created. Now, tell me, what am I doing wrong? >> And how can I become friends with Import again before I leave her for Include forever? |
| ||
| Include: Copies the code from the bmx into that place Import: Compiles the code and links the object file during linking stage against the other objects and forms a executable that way With quickbuild import is faster but there are situations you can not use it. (for example if you have cyclic object references or would get cyclic import structures which both is not allowed) Import is normally used to import a whole set of enclosed functionality into your application that has no outer world bounds to your app. Include is used in place where you want to interact between contents of files (as import is "fixed" before it is linked against your application so it will not know anything from your app!) |
| ||
| Yes, but, I still wonder, why does constants act so wierd? The constant I made for WIDTH and HEIGHT could not be used across the files that I imported, but that is okay. However, I couldn't reset new WIDTH and HEIGHT constants within the imported file either. It just complained about those constants already being set, even when I was unable to use them. So, I'm not allowed to use the constants, but I'm not allowed to make new ones either? Do I have to start using new names? Like WIDTH2 and HEIGHT2? Because this is turning really ugly. |
| ||
| I reserve Import for self-contained systems which have no integration to any other code than via their interface. For consts I would use unique identifiers relevant to the import code. I use includes more to keep code out of the way which *does* integrate with the main program. |
| ||
| But now they are one big clustered nonsense of spiderwebs. The answer to this is to have a clean object oriented design. Mainly things like high cohesion (making sure that all the methods that operate on a single object, are contained within that object) and low coupling (making sure that object only interact when absolutely necessary).This way using a tool like the UML Design Class Diagram, you can easily and quickly map out what your code does, and why making it a breeze to navigate (having a decent IDE doesn't hurt either). I also keep experiencing other small problems, like constants not applying over an imported source file, Make them a part of the object they're referencing. Now, tell me, what am I doing wrong? Numerous things. For starters you're using a technology designed for an object oriented process, in a seemingly strictly procedural fashion. This of course is not going to end well.A good book, if you care to read it, is Craig Larman's Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. |
| ||
| The Duck's not quackers. Design is the key. But I expect you knew that all along anyway. Can't say I've ever used Include. I don't even know why it's there, to be honest... :-p |
| ||
| I use include. Only to make my source files that I am currently working in smaller. Like if I have a few Types that all go together that are all kinda large. I break them into 3 files, and include two of them into the third. Especially if I am doing a lot of work on the third type still. Just makes it easier to navigate the file. I guess I could use folding and accomplish the same thing... |
| ||
| Head First OO Programming is a very good book as well. I use Include to create clusters/packages that I import (a cluster/package is a selfcontaining code system that might consist of a single or more objects, globals and constants) Why I use include: I use a single bmx per class, everything else is just ugly hackerstyle in an OO software system. In this cases include is needed as import wouldn't allow them to communicate as BM does not know of anything like header files and split class definitions. |
   |