On 24.06.2014 11:03, Thiemo Mättig wrote: 
I'm sorry but this is simply not true. All you need is a single additional
line of code.

With the proposed lists:

foreach ( snak in snaks ) {
    ...
}

With the current mappings:

foreach ( id in snaks-order ) {
    snak = snaks[id]
    ...
}

The current approach gives everybody the best from both worlds without the
need to implement, test, maintain, support and bugfix two different formats.

I really wonder why we are discussing this. Markus, just add similar
...-order arrays to places that miss them at the moment. Done.
As the one who is doing the JSON for the wdtk at the moment:

If I understand you correctly, you want me to keep an additional list for the order and the map itself. This will create a nice memory overhead if you want to process all the items.

The Json parser we intend to employ works by structural matching, so one will have a good time explaining him how to match list+map onto a list.
This would require some kind of Json post-processing wich in turn would slow us down. This is the exact opposite of what we want to achieve by using a more advanced Json-parsing solution.

I could in also argument that we keep the list and you can recreate a map from this list if you don't need ordering but want faster access.

We gain nothing by bashing use cases, they are diverse and all equally valid.




_______________________________________________
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech