AMQPWriter::write_array() doesn't support table array-members

[kernins]

Subj method threats both associative and indexed arrays as indexed, and so will lose array keys in former case. To be clear, I'm talking about nested arrays and is_array() check, not original argument itself.

Whether it is unlikely or not to have such complex structs in msg headers, it is theoretically possible, so should be properly handled or at least exception should be thrown.

[michaelklishin]

Other clients support such nesting just fine, so I consider this a legitimate bug.

[kernins]

There is also some sort of inconsistency here. write_table() requires types to specified explicitly, and write_array() instead performs some heuristics to determine types. But there is no fundamential difference between A and F, they're both collections, no reason to treat'em differently.

It would be much better to have such heuristics in a separate helper class instead. It would be usable for both methods and allow users to extend it if needed.

[kernins]

Currently both write_array() and read_array() omits type specifiers. This becomes a real hell on complex nested structs, especially read_table() result which is essentially a crazy mix of two formats in such cases.

So I have 2 questions:

• Would it be safe to make read_array() to return [type, value] tuples, just like read_table() does? It is not directly used outside of AMQPReader, but this will affect tables with nested arrays
• Would it be safe to make read_array() & read_table() to return objects implementing Iterator and ArrayAccess ifaces instead of plain arrays? Possible problems here are: typehinted someMethod(array $resultOfReadWhateverCall) and native php array-related functions.

[videlalvaro]

@kernins I'm not sure who might be using these functions at user land. So if they don't break users apps, then I'm OK for improving these methods