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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech