> Well, then were really talking about Classic Serialzation. In other > words, a program writes data somewhere (possibly in human readable > format), and then later (as in tomorrow) reads it in. Ok, lets start from there :D
> >>> Now, to know how to use the stuff, the program would need to not only be >>> able to handle the data structures, but also know their names. Sure, you >>> could have a parser that returns first the name of the thing, and then >>> the thing itself. But then, to use it, you probably couldn't have an >>> Universal program. Rather, you'd have to write the program different for >>> each time you decide to use a particular item from the scrap book. >>> >> The JSON parser does the same thing. You give it the name of the array >> you want to read. >> >> This is what the corresponding data files look like >> - JSON version >> "array" : >> [ >> [ >> [ >> 1, >> 2, >> ], >> [ >> 3, >> 4, >> ] >> ] >> [ >> ... etc :) >> -- >> >> -D styled version >> int[2][2][2] array = [[ >> [1,2], >> [3,4]], >> [ >> [5,6], >> [7,8]]; > > So, are we talking basically saving the state of the program for the next > run? Yes (also within a single run, but that doesn't really change things: same functions) >>> So here main has to know that there will be a variable i in the data >>> file, then get it, then presumably assign the value to the here defined >>> "int i;". This way you have to do everything (and more) you would if you >>> were to rename data.dat to data.d, include it, and then just use the >>> variables. >> The get function doesn't need to know that there will be an i in the >> data, >> it will just search for it. > > Exactly. The get function doesn't have to know. But the rest of the > program will have to know what to do with what get gives it. Right? > Actually, /that/ is what I'd see as the hard part here. Well at the moment that is the easy part: a class just has a load function which sets all kinds of vars to the loaded values. I already have my custom file loader, which isn't nice nor safe. >> If the JSON writer won't write every item (which will be thousands of >> items) >> on a new line and reading in multi arrays, then I think I need to witch >> to Tango :D > > No problem. I'm not here to "save you from Tango". :-) Took me a while to not read the oppisite. > > Okay, (I still feel I don't get it entirely), now I assume the thing is to > save the state for the next invocation tomorrow. > > Then I'd assume, you've basically got two things to do. First, write the > code to save basic data types, and then the code to save compound types > (as in structs, classes, trees, etc.). An OO approach would be to have > each class have methods to write and to read the data. I have this (except the OO approach) It can read arrays will a certain dept (3 deep I think) but the implementation is awefull, which made me think of what the more general solution would be. Which was a D styled dataformat :-D > > I can't help feeling that either using e.g. the Json parser, or writing > your own IO routines, should be the easy part. But then I feel using this > get function would be the harder thing. Why? In the load method within a class you would first have the correct file loaded and then a list of vars to set. > > Incidentally, Andrei is about to publish printing arbitrary data > structures in D (as part of Phobos), and if I suspect correctly, this will > also be done in a way that you can both write /and/ read stuff from files. > A little like Json. But of course, this might not be soon enough for any > real program for a customer. Wow, isn't this exactly what I wanted :D How do you know about this? If within a month that would be ok.
