Include inside a type
BlitzMax Forums/BlitzMax Programming/Include inside a type
| ||
In order to make my code a bit more manageable I would love to be able to...Type Blargh Include "Something.bmx" End Type I don't think this is possible at the moment, any ideas of a pre-processor exists that could let me do this? |
| ||
| Why not just include the whole Type? |
| ||
| I sometimes miss C style header files, especially for complex types with a lot of code. But I don't have any alternatives. |
| ||
Its so I can split a single type up across different files...Type Blargh Include "Something1.bmx" Include "Something2.bmx" Include "Something3.bmx" Include "Something4.bmx" End Type or maybe a better example... Type ExampleType Include "Consts.bmx" Include "Fields.bmx" Include "Methods.bmx" Include "Functions.bmx" End Type |
| ||
| I tried similar things in the beginning, but I don't believe you can do that. Instead I split my code into smaller "type-chunks" and put all includes in a file that I usually call xxx_Global.bmx. That file also has all global variables. |
| ||
Closest I could think of was this... not that I would do it myself! It's not ideal but would let you store the different 'sections' of the class separately...' fields.bmx: Type Fields ' In practise, something like Rocket_Fields, Rocket_Methods, etc... Field name:String = "Bill" Field a, b, c Field x, y, z End Type ' methods.bmx: ' -- ' Import fields.bmx Type Methods Extends Fields Method Whatever () Print Self.name End Method End Type ' complex.bmx: ' -- ' Import methods.bmx Type Complex Extends Methods End Type ' MAIN PROGRAM... ' -- ' Import complex.bmx Local example:Complex = New Complex example.Whatever You have to be careful of the order they extend in, too -- if fields imports methods, for example, then the methods can't access the fields! |
| ||
| currently you can't do this, but i have thinked about this and what if we modify current maxide source and add this "prefix" system... just put those "prefixes" to comment line... example:
'#define debug_only '<= define debug_only pre_variable
'(^^ easy. just put "debug_only" key and null to TMAP)
'#ifdef debug_only
'if _define:TMap.Contains("debug_only") then ->insert code
'<all code in here is remmed if debug_only is NOT defined or is false
'#endif
'^^ end ofDefine if block..
'#include "some code.bmx"
'^^ this will just insert code from "some code.bmx" to this position
Last edited 2012 |
| ||
| No please! That would make code context absolutelly unpredictable. IF you have a class this big, time for a redesign or split functionality into smaller classes. Monster-big classes are the mother of never-ending maintenance costs and spagetti code |
| ||
| Zeke, couldn't the source be altered to show/hide the function or method code? That would be tidy. Like the editors of yesterday. |
| ||
| That would make code context absolutelly unpredictable. Second that. If your class is that big, something went wrong in the first place. |
| ||
| If your class is that big, something went wrong in the first place. Not necessarily. With separate header files it's easy to scroll through a class header and read its interface and get a feeling for what's going on. In the MaxIDE, your class interface is muddied by a tonne of method and function code. Even with a fairly minor type it's unlikely you'll be able to see all it's methods and fields on one page. I ain't complainin', jus' sayin' ^ what happens when you post listening to Muddy Waters |
| ||
| While that is true, it is also more of an IDE related topic in my opinion. BRL's MaxIDE at least shows all methods and functions of a Type in the code view. Also the whole concept of "One class, one file" is nice and easy to work with. I imagine it to be kind of confusing to seperate the logic like that. If you're desperate, you can also check the interface file for a module eg "brl.mod/event.mod/event.release.$your-os-here.i" :'D |
| ||
| I don't think allowing includes in the type should be introduced. The type is an object and should be thought of as a self contained unit. A better idea would be to allow collapsing of the type and/or methods at their name while still showing the name and parameters. Browsing through large types would be visually easy with only the method lines on show. It would look similar to a header file to browse through and also turns the issue into an IDE one instead of a language one, as already mentioned. |
| ||
| Seems a bit PHP'y for me, which is fine for PHP, but, I wouldnt like to see it in BlitzMax! Dabz |
   |