Framework question
BlitzMax Forums/BlitzMax Programming/Framework question
| ||
I was experimenting with Framework and found the following code wouldn't compile:Framework BRL.Blitz Framework BRL.StandardIO For a = 1 To 10 Print "Test" Next I get a "Framework does not match commandline framework" error. Now, since the BRL.Blitz module contains "For and Next" I thought for sure I'd have to include that. But, if I comment out the first Framework line it compiles just fine, even though the only commands inside BRL.StandardIO are Print and Input(). Any ideas why this is so? Russell |
| ||
| after the first framework, dont they all have to be import? Like: Framework BRL.Blitz Import BRL.StandardIO |
| ||
| Yeah. Only one framework per program. Any ideas why this is so? Nope. |
| ||
| If I comment out the second Framework, I get "Identifier Print not found". Commenting the first one gives the error described in my original post. The thing is, with the first one commented out, it compiles fine and is only 91.5k (compared to 2.21MB without Framework). So, something is happening, even without 'Import'. Just wondering. Russell |
| ||
| Framework BRL.StandardIO Framework Assistant is fantastic |
| ||
There is no actual code in BRL.Blitz for For..Next. That's handled internally within the compiler itself. So you don't need to actually import that module for the For..Next command to work. The module does have an entry for it for bbdoc.Rem bbdoc: Marks the start of a loop that uses an iterator to execute a section of code repeatedly. keyword: "For" End Rem |
| ||
| Ah, well that makes sense then, since For/Next (and While/Wend, and other looping or branching structures for that matter) are not really what you would call functions. Still, the fact that For/Next is listed in the BRL.Blitz module section of the built-in help made me think it would have to be manually included. Are all of the BRL.Blitz commands handled internally? Anyway, thanks everyone. Russell |
| ||
| This is the reason we need good documentation. If the BMAX documentation was correct, a person would not have to "EXPERIMENT" to get something to work. |
| ||
| The plot thickens..... Ok, so I have a look at "Import" in the built-in help and it shows this example: Rem :Import specifies the external BlitzMax modules and source files used by the program. End Rem Framework BRL.GlMax2D Import BRL.System Graphics 640,480,32 While Not KeyHit(KEY_ESCAPE) Cls DrawText "Minimal 2D App!",0,0 Flip Wend Instead of making it clearer, it is even muddier: None of these commands are located inside BRL.System or BRL.GLMax2D, so what is the purpose of Framework and/or Import? (i.e. Graphics/Flip are inside BRL.Graphics, While/Wend/Not are inside BRL.Blitz, KeyHit() is inside BRL.PolledInput, and Cls/DrawText are inside BRL.Max2D) So what am I missing here from a "What does it actually do" point of view? Why does the example above compile, when none of the commands from it are included in the specified modules? I'm waiting for that 'Aha!' moment to hit me like it did when I first encountered types many years ago on Blitz Basic 2 on the Amiga. Russell |
| ||
| The BRL.GLMax2D module itself imports other modules like BRL.Graphics etc So although BRL.GLMax2D doesn't contain the functions required, it does import those necessary modules that contain the other funtions. Look at the source code for the BRL.GLMax2D module and all will be revealed :) |
| ||
| Ok, that makes sense. I suppose the same can be said for BRL.System? I'm still unclear on why we would only use one Framework command, rather than a Framework for every module we want to include. And Import doesn't do the same thing? I'm almost there, VIP3R! Give me a push! Russell |
| ||
| Framework tells BlitzMax not to import all standard modules. If you just said Import brl.system, it would import everything else too. If you say Framework brl.system, it imports nothing BUT brl.system, which is why you can't use it more than once. You've already used it so it would be counter-intuitive if it then removed what you said you wanted to import. |
| ||
| Yep, same applies to BRL.System and any other modules you import. You need to specify the initial module with Framework to tell the compiler that you want to import only the specified modules. Once done, you don't need to tell the compiler again, so you only need to import them to 'add' to your existing framework. [edit] In other words what Gabriel said :) |
| ||
| If you say Framework brl.system, it imports nothing BUT brl.system, which is why you can't use it more than once. Because Framework is not inside BRL.System, and therefore a second Framework would not be recognized? If that's the case, that's silly, because Framework is a compiler directive, is it not? You've already used it so it would be counter-intuitive if it then removed what you said you wanted to import Well, true, if it works in an 'exclusive' only mode. Intuitively speaking, it would make sense to add allowed modules to subsequent Frameworks or allow multiple module includes on one line: Framework BRL.System, BRL.Blitz and so on. But hey, I can deal with it the way it is, even if it isn't 100% intuitive (or explained very well in the manual) ;) Russell |
| ||
| Because Framework is not inside BRL.System, and therefore a second Framework would not be recognized? If that's the case, that's silly, because Framework is a compiler directive, is it not? No. Take this example : Framework BRL.System Framework BRL.Blitz The first line says "Import no modules except BRL.Mod1" The second line says "Import no modules except Brl.Mod2" So in other words, the second line, removes the module you just imported with the first line. It's counter-intuitive to allow this. It's a compile-time directive, so you can't change your mind in the code. There's no purpose to doing it twice. It's nothing to do with the modules which contain Framework, as it's not in a module, as you say it's a compiler directive. Intuitively speaking, it would make sense to add allowed modules to subsequent Frameworks Not really, because Framework is for removing modules, not adding them. By default, they're all added. Framework is saying, don't import them all, I only need this one. or allow multiple module includes on one line: Teah, that'd be fine. It's only alternative syntax to a feature we already have, but it would be perfectly intuitive and wouldn't break anything. I'd have no problem at all with that alternative/additional syntax. |
   |