Why doesn't the BlitzMax compiler...
BlitzMax Forums/BlitzMax Programming/Why doesn't the BlitzMax compiler...
| ||
| ...detect and only include the modules it needs automatically? I know you can use Framework but surely if Framework Assistant can work out exactly what you need so easily, why doesn't the BMax compiler? It saves having to use different utilities and I can't see a reason why having modules you don't use included - unless people like unnecessarily large programs. :-) The only problem I can think of is with driver modules - choosing the audio/graphics drivers, but surely you could specify this additionally (if you wanted to). What does everyone else think? Am I missing something blindingly obvious (or is it just a case of Mark having more important stuff to do, like 3D stuff :-P)? |
| ||
| It's entirely possible to define types and functions in different modules with the same identifiers. An intelligent compiler could look at the context in which they are used and decide which module to use, this is not guarenteed to work 100% of the time though. I personally think such a feature is unneccesary. But I would say that, I'm the type that uses superstrict, won't use variable tags and resent the fact that when I import a module it will also import any externally referenced modules into my namespace without my say-so. Such a feature would have to be optional or I'd be very unhappy. This sort of thing makes things like IDE's harder to build as you effectively have to replicate the behaviour in your source parser and makes things like code-completion uneccesarily complex. And for what? The sake of a few Import statements at the top of your code? However, considering Blitz's heritage I respect the fact it needs to be accesible to a broad userbase. |
| ||
| Auto Framework Assistant, I like it :) |
| ||
| Framework Assistant - I still have to go back and make sure both grapics drivers are available, it never accurately detects the app needs both. But otherwise, I agree with the first post, it should be on auto pilot for this stuff. ;) |
| ||
| With reflection being added, this moves from difficult to autodetect (eg pngpixmaploader/max2d) to impossible. Really, doing Framework isn't too much trouble (though I don't even bother). |
| ||
| What if I'm using Rand(), but I don't want it to use the default BRL.Random, but rather my own, improved BaH.Random module? The same goes for image loaders... etc. Doesn't seem like a big hassle to type Framework and a couple of Imports... :-p |
| ||
| What if I'm using Rand(), but I don't want it to use the default BRL.Random, but rather my own, improved BaH.Random module? They could implement some sort of list of modules being used by the current file and have multiple choices (if there are any) for a particular module, so you can pick whichever one suits your likenesses. |
| ||
| And? Bah.Random and BRL.Random would list the same functions, which one is the compiler meant to use? its not god, no chance for him to autochoose. multiple choice is no compiler function. If you as programme don't know what you are programming, then its really your problem ... import and framework is already much less of a problem than include chains are in C / C++ thanks to a million .h files to include ... |
| ||
| If you use BLIde, then Framework Assistant operates as a BLIde plugin. Don't bother using Framework/Import during development, because you'll be forever updating it. Run Framework Assistant once, at the end. It'll take you about 30 seconds, tops. |
| ||
| It will take forever updating and using framework during dev will most likely cause untrackable bugs in some cases which you better avoid, due to moved functions in BRL / PUB modules. |
| ||
| An update to my post. The problems I decribe are false. You won't get identifier conflicts as module members can be referenced by prefixing the module name. Rather embarisingly I'm forgetting that by default Blitzmax imports all modules if a framework is not defined anyway. So in answer to your question Seb there's no reason why the compiler couldn't only link modules that are referenced by your source directly or indirectly, nothing would be broken. As you say I would think it's only a matter of priority. |
   |