Yes, STON uses depth-first traversal of the object graph. Since it uses numbered references, the traversal has to be fixed. This excludes other traversals, as far as I can see.
On 26 May 2016, at 22:00, Peter Uhnák <i.uhnak@gmail.com> wrote:
At a first glance it seems to me that it uses DFS instead of BFS, because it doesn't distinguish what is it actually following. So maybe the strategy could be to follow BFS and use subinstances of Collection as references.
Peter
On Thu, May 26, 2016 at 9:20 PM, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote: Hi,
I didn't find that strategy and finally created a #flatten method before serializing my grafoscopio trees, with just what I wanted. At [1] you can find the last version of the notebook show at this screenshot:
<ffcheafc..png>
[1] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212
I know is this doesn't solve in anyway your problem... but may be it could inspire you in some way. I was asking also for a flatter STON and the idea of a method to flatten the tree wrote by myself was not evident at the beginning, but was a very good solution.
Cheers,
Offray
On 26/05/16 13:52, Peter Uhnák wrote:
Hi,
is it possible to configure STON to generate more flat output?
Imagine a scenario where an element can have children and the children have reference to their parent
<Mail Attachment.png> â Now the problem is that the output of STON will depend on the order of the items, so if I have "nice" ordering for the following, I will get a flat output
<Mail Attachment.png> â If however the ordering is different, the output will be more nested
<Mail Attachment.png> â As the ordering is not stable, I often end up with results like this (zoomed out)
<Mail Attachment.png> â The image above has depth of about fourteen, even though it could be represented with just depth of four.
In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs.
So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels.
Thanks, Peter