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.uh...@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.l...@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 >> > >