How to pick name at runtime?
BlitzMax Forums/BlitzMax Programming/How to pick name at runtime?
| ||
| Say you want to restore the datapointer to some name, but during runtime, not during edit time. How do you pick a name at runtime? Dynamically. Some dialects may use read..data and use restore a$ for example. Is it possible in Bmax? Local a$ = "labelhere" Local b$ = "" ' Read and print RestoreData a$ ; ReadData b$ ; Print b$ ; WaitKey #labelhere DefData "When you're curious, you find lots of interesting things to do." |
| ||
Do you mean you want your code to operate differently whether or not you are in DEBUG BUILD or not ?Graphics 170,20 ?Not debug DrawText "COMPILED IN FINAL",15,4 ? ?debug DrawText "COMPILED IN DEBUG",15,4 ? Flip WaitKey... ??? Actually I see what you are attempting. a$="apple" RestoreData a$ ReadData a$ Print a$ #apple DefData "delicious."No, I don't think you can do this. HOWEVER, you can make a look-up table of sorts. a$="orange" If a$="apple" RestoreData apple ElseIf a$="banana" RestoreData banana ElseIf a$="orange" RestoreData orange EndIf Print a$ ReadData a$ Print a$ #apple DefData "Delicious." #banana DefData "Mellow." #orange DefData "Tart."Hope This Helps ! |
| ||
| You can use function pointer and restore the data label in functions While there is probably a better way, it's how I would do it. |
| ||
| Hmm, Bobysait, you just gave me an idea. |
| ||
| Thanks both, great examples. The thing is I try to create a framework. Say the user put a library of files each being a defdata section with its own name. I have a bunch of methods in this framework that should do some work on this data. My best guess now is to set a standard and use sterile IDīs (e.g. 0-9999999) that doens't change, (so you can hardcode them as you did with case or functions) and put the name first like dw817's last example so the names become a part of the datastructure itself. But then you have the problem how to mix and match several datatype when you donīt know what's coming next, I guess that could be solved though. The simplest would be to create some standard there too, or base64 or something. Are there any other ideas? |
| ||
| Thanks Casaber. I thought it was a pretty neat way to retrieve data by folder. :) And no, you can mix and match data types no problems. Lemme try another example. Howzzat ? |
| ||
| Similar to dw's code you could store your code with some delimiter and use it like a flat-file-db. So you have defdata in form of "bla|valBla||blubb|valBlubb||blip|valBlip" and split it according to your needs (key|value || key|value || key|value). BUT ...as you design it before runtime, you already know what you need to use when and where - so you end up with if-then-else or Select-Case-Default bye Ron |
| ||
| Just remember, Casaber, as my friend Chris tells me. KISS ! "Keep It Simple Stupid !" While there are indeed a great number of immensely powerful libraries out there that can assist you, you will find it is better to KNOW simpler code and use it rather than to simply ACCEPT more complex code that you don't know how it works. |
| ||
| DefData is simply not good enough for generic stuff because it uses hardcoded labels. If i had to use it, i would specify a requirement for the user of the library to call RestoreData before calling any of the data handling routines. Or even better, take Bobysait's example and require the user to register a function that only calls RestoreData instead. |
| ||
| I just have to ask. Is there a specific reason you need to use DefData? Its really slow and cumbersome to use when there is IncBin. Even mark himself have said so, it being a throwback for compatebility with other basics. The only reason i could think of to use it is for source only releases, like on this very forum. |
| ||
| Its really slow and cumbersome to use It also takes up *at least* twice the amount of memory to store numbers than say IncBinn'd data. |
| ||
| I could definitly use IncBin equally well but I would still need the gest of a dynamic pointer, something to refer things by programatically without hardcoding them. I usually do use Incbin and I just re-discovered data statements they are nice for hands-on access, I wanted to explore things abit. The reason I need the programatically I should explain better I think. Imagine you want to create a new command, which should take a datadef or incbin (or both) as input, and read that. Without ever lifting the lid on it and editing/hardcoding a list? How would you do that? |
| ||
| You just cant with DefData, unless doing as suggested above. With InbBin, you use strings anyway so stashing that wherever fills your requirement. Or are you looking for a way to lookup ALL data pieces dynamically? If so you can do that with IncBin too, though you would have to modify blitz.mod/blitz_incbin.c since its list is static. |
| ||
| Grumble mumble. :D Sure there are better ways to do this. I could be busting butt learning machine-language to write my stuff in too, but I don't, I'm a lazy sod so I choose BlitzMAX. And BlitzMAX chose to have DefData() for people to use so it can't be all that bad. :) Simplicity vs Complexity Limitations vs Diversity These constants of creation and inspiration will always be there. Always striving to balance the two, to gain simplicity with diversity - can't always be done. |
| ||
| Sure, we can do whatever we want ;) But then one also has to accept any limitations that comes with that choice no? Im not saying no one should use it, or deriding anyone that does mind you. Personally i prefer to use arrays if the data needs to be at source level. Since then i dont have to interpret the data before using it, and in most cases the data ends up in an array in the end anyway ;) But if the data is complex and interpretation IS needed, i would rather generate the code+data instead to get a complete "package" if you will. Im pretty lazy too you see, so if i can generate it i will! :p |
| ||
| I was actually thinking of building a crazy image saver thingie for Monkey-X where it was just a series of PLOT statements. It'd be really fast but WOW the sourcecode would look awful. :D So - I see what you're saying here, Grable. And yes, direct values into an array do make more sense than DefData as ultimately that'll be where it goes. global die[]=[1,2,3,4,5,6] Global die[6] RestoreData diedata For i=1 To 6 ReadData die[i] Next #diedata DefData 1,2,3,4,5,6 |
| ||
| Good analogy about arrays, I totally agree about that ya. Mixing datatypes within arrays could be done nicely with structures somehow in BMax I guess so that's no problem? |
| ||
| It's still unclear what exactly it is that you want from the user. You're doing a framework for what? What does it do? What kind of data does it need from the user? In any case, if you require data from the user then it's likely to always be a defined set of values and types, so you can pack it all up in a class and have a clean and safe way of transmitting it. EDIT: Improved the example. |
| ||
| Really nice suggestions coming in here. Really appriciate it. Basically I'm creating new instructions which need DATADEF or INCBIN as parameters and read that data. Frankly INCBIN which uses strings had slipped my mind, that will be perfect. So that's what I'll do for starters it makes most sense and would be very simple to do. If I ever need something more open such as DATADEF, I will try use ARRAYS as mentioned above I think. With INCBIN i could have compact binary files, or even CSV or JSON structures which I could stream like READ DATA does. Iīm will keep my eye how compact or wasteful data will become, but I like the simple idea. |
| ||
| I would do as suggested... create a simple tdata object with getters and setters and then leave it up to extending classes to take care of various defdata-datatypes... so one for json, one for memorydumps... Reading them in should be done in a assignData(data:object) way. If you then create a dataCollection container this could hold all defined (or undefined...with defaults) data with simple getters too. Bye Ron |
| ||
| I like to to play with the thought of using all those examples, going with my gut though. I'll show how I did it, this is a KISS way doing it. I value terseeness and clearity and I know what happens if I do not.
' Grouped named data heres
Incbin "datanamehere"
Incbin "otherdata"
' Example how to use it
commandname("datanamehere")
' Actual code behind the command
Function commandname(a$)
anycommandccessingthedata "incbin::" + a$
EndFunction
|
   |