On Apr 6, 2010, at 3:37 PM, Krzysztof Kosiński wrote:
W dniu 6 kwietnia 2010 23:58 użytkownik Yann Papouin <yann.papouin@...400...> napisał:
Following is an example of what I'm applying in my software:
[SNIP]
In C++, I would do something like this. It's practically the same idea, but switch + fallthrough makes it clearer.
That's a good initial approach. However there are several cases we've gone over in the past that make a simple case-statemt sequential update not the best choice.
A lot of this has to do with decisions on Inkscape release versions, incremental updates, etc. There are several situations you can get into where this approach will actually lead to data loss.
case 0: fix_3dbox_coords(doc); fix_guide_coords(doc); case 1: add_flowtext_fallbacks(doc); case 2:
Now that is starting to be quite helpful. Are those actual cases you've hit on, or just representative of what *might* need to be done to be compatible?
Regardless, breaking down things in that manner really helps to reveal some patterns. And one of them I see right at the start is the general one to avoid *version* checks and instead go with *feature* checks. In the abstract this is exactly the same thing that Microsoft warns developers about using various Windows APIs.
The fixup functions you have listed there definitely look like they are organized based on "features". That's very good. If we take that and expand on it a little we can get something quite robust that also will be able to minimize data loss. (let me know when you've got this started in a wiki page and I'll see what past cases we've covered that need to be included). It also is very helpful that you have each 'version' broken into separate logical sub-fixups.
Regardless of what this function will ultimately do, we'd need to create several test documents for every document format change, and verify that the conversion works correctly after every change to older portions of the update procedure.
Yes. You are right. This is a very important step. In fact, this might even be a good first step. Even if we don't actually need the functionality for older versions we can go ahead and collect up some samples of when we've done such breaking changes in the past and then see if they match our expectations. Then we can also expand the set forward with *anticipated* breaking changes such as those related to the coords flip.