On 14.04.25 04:31, ichthyo wrote:
My plan looks as follows: - create a copy of the existing XMLwrapper - re-order existing functionality into three layers + the front-end used by Yoshimi core logic (I'll call this "XMLStore") + a new internal abstraction of an XML subtree (I'll call this "XMLtree") + a back-end or policy class which exposes some relevant base operations of lib MXML, to the degree necessary to implement "XMLtree" - next step is to simplify the XMLStore (front-End) and remove the unnecessary statefulness (esp. the context stack adds a lot of complexity and it seems it can be replaced by direct navigation functions of MXML)
Hi Yoshimi-devs, with my recent changesets, I completed an important step, which is to work through the existing code and reorganise it. Now I was able to remove all of the complicated stateful logic with the context stack. Furthermore, the new implementation does no longer *depend on SynthEngine or Config internals*, while in turn the *MXML include* can be confined solely to XMLStore.cpp My simple test case works (again), can create a new empty XMLStore or load an existing file, add elements and render it back to disk. The *next step* will be a bunch of repetitive work (doh!). I'll have to go through all usages of XMLwrapper and switch them piecewise to the new API. While /effectively both interfaces are equivalent/, they are based on a different usage scheme, which makes this next change rather pervasive. Let me explain: - the old interface had a XMLwrapper object with an implied "current location". That means, it always pointed implicitly at some "cursor" in the tree, and all code had to navigate that cursor and "open" and "close" branches. - to the contrary, the new interface is "DOM-style" When you access a sub-node, instead of "navigating" an internal state, you get a new XMLtree object, which points at the nested node. Then you use the latter to access data or add new elements. When done, you simply let it go (MXML uses ref-counting internally) The notable effect in the code will be that we'll get lots of explicitly named temporary objects, pointing at some sub-elements. Through this explicit naming, the code should become more readable and clear. And on top, the new scheme has the benefit that it is no longer possible to forget that notorious exitbranch(). As said, the current state is on my MXML branch; Working through all that existing usages will take some time... -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
