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