TYPO3.TYPO3CR

A warning is probably not be what people would like to see...

Anyway, JSR-283 (as well as JSR-170) only support array-like multi-valued properties, and arrays simply do not have "named keys" in Java; a hashmap is used for that instead. Thus we need to store those "associative arrays" differently. One way could be:

N flow3:someobjectinstance [flow:]
  P name = cool
  P foo = bar
  P scores = [1, 3, 2, 6, 1, 1]
  N members [AssociativeMultiValuedProperty]
    P foo = bar
    P lame = duck
    P another = item

Legend: N = node, P = property, [something] = node type

for an object having two simple properties, one numerically indexed array and one associative array.

There is still an open question: what about numerically indexed arrays whose keys are "used", i.e. carry meaning? It is impossible to detect those, so maybe we need another annotation (e.g. @preservekeys)?

Karsten Dambekalns wrote:

There is still an open question: what about numerically indexed arrays whose keys are "used", i.e. carry meaning? It is impossible to detect those, so maybe we need another annotation (e.g. @preservekeys)?

That's difficult ... If in doubt I would look at what the user would expect to happen: If she doesn't know about the special annotation, she would be surprised to find out that all keys are gone.

BTW, interesting in this regard is also the planned SplFastArray: http://www.colder.ch/news/06-07-2008/33/splfastarray-to-speed-up-.html

If people would jump on the SplFastArray wagon, that would make life easier. We could store SplFastArray as simple multi-valued properties, and regular arrays using the more complicated construct proposed above.

Still I would like to avoid using that construct more than needed, as it smells of performance loss. Hm, I guess I shoud try that and actually measure...