Request: DirectInclude
BlitzMax Forums/BlitzMax Module Tweaks/Request: DirectInclude
| ||
| I'd like another include-command which just copies the content of a specific file to the command's position right before it compiles. It's because I've really really big Types which I just can't split up at the moment. |
| ||
| There is an include command, e.g include "mytypes.bmx" |
| ||
| Yeah, I know. But this one won't work inside a Type, inside an if-block or inside anything else. That's the problem. |
| ||
| I think Its a stupid Idea to split a type or an If block or anything else accross different files. If your type is "really really big" then 1) Live with it. 2) Rewrite it so that one type contains bits of another type. |
| ||
| I also don't see the deeper sense in this request. The issues caused may be just the result of "bad" coding. |
| ||
| You didn't name any reason, why not. Because it is a "stupid idea"? Well, that's your opinion. It can't be too difficult to implement and I think, it's worth it. 1) Not if I can solve this problem ;) 2) Would be moooooore work than just implementing this Include-"Feature". And unlike programming a little "DirectInclude", rewriting my type would be _not_ worth it. It's just not the right work/use - relation. |
| ||
| Reason against it: It would make scope checking very time expensive as it must recursively test all declarations for each of those files. This can't happen with normal include / import as they must be done before any internal declaration. Thus -> unwise idea with no deeper use than "just for beeing there" There is no reason to do something like that. If you need the same code several times across different places, there is something hyper magical called "FUNCTION" which exists exactly for this reason: reusing the same functionality at different places. If you want to clone the same type declarations, looking at extend and abstract might be something as well (at least for field and const) |
| ||
| <<<<<<<< There is no reason to do something like that. If you need the same code several times across different places, there is something hyper magical called "FUNCTION" which exists exactly for this reason: reusing the same functionality at different places. If you want to clone the same type declarations, looking at extend and abstract might be something as well (at least for field and const) >>>>>>>> Neither the first nor the second reason is why I want this. I just want to split one of my Types up and put the content into several files. >> Reason against it: It would make scope checking very time expensive as it must recursively test all declarations for each of those files. In this case, it's not a real reason. If it checks one file or two with the same content, what's the matter? It has to check the same code anyway. Also, I don't request for changing the existing "Include". I ask for another Include-Command which uses my suggested behaviour. |
| ||
| You could use a pre-processor perhaps. |
| ||
| @There is a hyper magicla called "FUNCTION"... @Dreamora, thats very patronizing ;) @Fetza, I could if I could be bothered defend my position about why its a stupid Idea to split a Type over several files. (And Im assuming that you are only talking about methods). However I wont. I Think, (Notice word think), that its a STUPID idea to split a Type over several files. If I wanted to do that I would group bits that I wanted together, and make a type of that. Then I would either Inherit from that type, or include it as a field. |
| ||
| >>>>>>>>>> @Fetza, I could if I could be bothered defend my position about why its a stupid Idea to split a Type over several files. (And Im assuming that you are only talking about methods). However I wont. I Think, (Notice word think), that its a STUPID idea to split a Type over several files. If I wanted to do that I would group bits that I wanted together, and make a type of that. Then I would either Inherit from that type, or include it as a field. <<<<<<<<<< Well, you don't have to use a possible "DirectInclude" if you don't want to. ;) I still have no better Idea how to tidy a big Type up without recoding everything into several Types. Do you? If not, I'd suggest you to tell me, why you are against implementing that command. As I said, you're not forced to use it. I'd find it very helpful. I'm not yet convinced, that there is a real disadvantage. @Beaker Yeah, I thought of that, too.... but I didn't find any matching Preprocessor and I assume, that I'm not able to write one myself. |
| ||
| If the import/include is done at beginning, the scope checking has to be done once and only for that file. But if it appears in the middle of the code it must be redone everytime once again to see if it interferes with a declaration. Why do you want to split the type into several files? If you plan to split implementation and declaration of the type: That won't work even with a direct include as the compiler is unable of this distinction. One thing I haven't tested: Couldn't you split the type up to several files and include them all together to a new file which you include / import into the bmx you need it in? |
| ||
| Ok fair enough. I still have no better Idea how to tidy a big Type up without recoding everything into several Types. Do you? Use an editor that folds methods and types. Al la BLide. http://www.blitzmax.com/Community/posts.php?topic=60407 BUT honestly even if you couldnt fold, its still a stupid idea to split types/ loops over several files. It dosn't matter how big you think the type is. Its never going to be a good idea. I realise that this type is "finished" so you believe that it would be a big job to break it down, but 1)It would still be the best way, 2) Just learn from it, and dont make one so "big" next time. As a point of interest, how big is it? @Dream, the whole splitting thing falls down anyway when you thinkon about how Private and Public work in BMax. (Now That IS somthing that could do with changeing) |
| ||
| >>>>>>>>>>> Use an editor that folds methods and types. Al la BLide. www.blitzmax.com/Community/posts.php?topic=60407 <<<<<<<<<<< Oh, dear god, not BLIde! I ha.... don't like BLIde, because I really loose any hint of what's going on when I'm using it. There are far too many buttons, toolbars, sub-windows and everything. It's "overloaded". Anyway, it is just not my IDE. Can't handle it. I'm hoping for MaxIDE Community Edition to be a better IDE than BlitzMax originally has. That's it for me at the moment. >>>>>>>>>>> BUT honestly even if you couldnt fold, its still a stupid idea to split types/ loops over several files. It dosn't matter how big you think the type is. Its never going to be a good idea. I realise that this type is "finished" so you believe that it would be a big job to break it down, but 1)It would still be the best way, 2) Just learn from it, and dont make one so "big" next time. <<<<<<<<<<< Yeah, I won't code another Type this big in future. There are many possibilities where I could have split up the whole thing, but I didn't realize the problem at that point. Now it's too late. Well, the Problem is not *that* big, but I've already given all Functions and Methods a Prefix to tidy things up. Now it would be great if I could get all of them out of my mind, I don't need currently. That's why I want to split it up into several files. >> As a point of interest, how big is it? 8682 lines. It is the "Ship"-Type of a Spacegame and I already derive it from "GameObject" which contains all the lowlevel-stuff like Movement. What makes it that big is Equipment- and Cargo-Management, AI, Controls and Status-Report-Methods. I should have had an extern type for "EquipmentSlot", "Equipment", "Cargo" and "AI". I'm already proud of having extern "Player"- and "Camera"-Types. |
   |