D-styled data file

[Saaa]

> 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.