View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000698 | LDMud 3.6 | LPC Language | public | 2009-11-01 03:44 | 2021-04-16 22:27 |
| Reporter | _xtian_ | Assigned To | Gnomi | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.6.3 | ||||
| Summary | 0000698: Make different versions of a struct compatible to each other | ||||
| Description | As there seems to be some interest in making structs-children and struct-parents polymorph - *yippie* ;) - , I thought I'd add another issue that may be similar. One negative issue with structs is that they may not be saved/restored without complications. Technically it is feasible, but practically speaking struct definitions change over time and old struct-definitions will not be compatible to newer ones. Then the struct in the save-file will not be able to restore properly. (so what I do is to use mappings whenever I have to store data) It would be great, if older structs could restore to newer variations of its definition. Mostly this will just be adding or maybe removing an element of the struct. | ||||
| Tags | No tags attached. | ||||
|
|
Mhmm. I just had a look at this stuff. Basically, the struct is searched first in the objects program (including inherited programs). If that fails, the struct is searched in the program given in the savefile itself (so you can restore a struct into a <mixed> without inheriting the struct definition). If the savefile has more members than the current struct definition, the extra members in the save file will be silently ignored. If the struct has more members than the savefiles, these will just be 0. So far, so good. But if you change the types... Well the struct will still be restored. The data will be assigned to the current structs members in the sequence they are in the savefile. Example: struct a_s { int a; string b; }; Savefile: a_instance (<"a_s players/zesstra/i1.c #1469",42,"Foobar",>) If I change a_s in the meantime to: struct a_s { mapping a; string b; }; I can still restore it. But obviously, a_instance->a has now a incorrect type. So technically, older structs can restore to newer ones, but the result may not always be desireable. In case of wrong types, this can be checked upon restore and I would seriuosly consider to raise an error if the types are not matching. But then another example would be if I insert something at the beginning of the struct, like: struct a_s { int ref; string name; int a; string b; }; Now, this we can't detect at the moment. The old struct will be restored, by now ref would be 42, name "Foobar", but a and b would be 0... For preventing the latter case, we need another savefile format, which includes member names (like mappings) and does not rely completely on the sequence of members in a struct. Either use a format similar to mappings or find a way to save struct definitions in a savefile and compare that to the current struct upon restore. |
|
|
save & restore of different struct versions is implemented in 3.6.3 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-11-01 03:44 | _xtian_ | New Issue | |
| 2009-11-02 09:38 | zesstra | Note Added: 0001581 | |
| 2009-11-02 15:20 | zesstra | Relationship added | related to 0000699 |
| 2021-04-16 22:26 | Gnomi | Project | LDMud => LDMud 3.6 |
| 2021-04-16 22:27 | Gnomi | Assigned To | => Gnomi |
| 2021-04-16 22:27 | Gnomi | Status | new => assigned |
| 2021-04-16 22:27 | Gnomi | Status | assigned => resolved |
| 2021-04-16 22:27 | Gnomi | Resolution | open => fixed |
| 2021-04-16 22:27 | Gnomi | Fixed in Version | => 3.6.3 |
| 2021-04-16 22:27 | Gnomi | Note Added: 0002620 |
