Over time I\'ve rolled my own formats for saving and loading object properties but on having to revisit this I\'m wondering about using Delphi\'s own text DFM format. I know
I wouldn't really say that DFM is an 'internal format'. Sure Delphi uses it internally for forms and datamodules, but TReader and TWriter classes that perform streaming are publicly accessible and even documented. So they are clearly intended for end users as well.
Now, the possible problem is when you save a stream and later one of the classes in the stream changes so that the stream is not compatible any more. You may have seen this in Delphi if you attempt to open a form saved in D2007+ in D7 (missing property). But even if it happens, it's not too hard to resolve. You will get an exception that will report the exact property that is causing the problem. You also have to register all classes that you want to stream with RegisterClass
.
DFM can be stored in binary or text format. Even if you store it Binary you can convert it to Text (using ObjectBinaryToText
), once in text format, it's easy to fix.
So, the problems you may get happen due to incompatible changes in the structure, but those have nothing to do with DFM mechanism itself, and would also happen using any other streaming mechanism.
As for longevity, you can still open DFM's saved with D1 in the latest Delphi. So as long as you keep backward compatibility in mind, you have nothing to fear.
In conclusion, the choice of any particular format, DFM, XML, JSON, your own... doesn't really affect longevity. They all require same level of compatibility.
The reasons for choosing the format have more to do with decisions regarding:
But you didn't mention any of those in the question.
So I suggest using DFM over roll your own, as it would mean less code to maintain.