I prefer to read and write clean code - as outlined in "Clean Code" by Robert C. Martin.
When following his credo you should not require the developer (as user of your API) to know the (internal) structure of your array.
The API user may ask: Is that an array with one dimension only? Are the objects spread around on all levels of a multi dimensional array? How many nested loops (foreach, etc.) do i need to access all objects? What type of objects are "stored" in that array?
As you outlined you want to use that array (which contains objects) as a one dimensional array.
As outlined by Nishi you can use:
/**
* @return SomeObj[]
*/
for that.
But again: be aware - this is not a standard docblock notation. This notation was introduced by some IDE producers.
Okay, okay, as a developer you know that "[]" is tied to an array in PHP. But what do a "something[]" mean in normal PHP context? "[]" means: create new element within "something". The new element could be everything. But what you want to express is: array of objects with the same type and it´s exact type. As you can see, the IDE producer introduces a new context. A new context you had to learn. A new context other PHP developers had to learn (to understand your docblocks). Bad style (!).
Because your array do have one dimension you maybe want to call that "array of objects" a "list". Be aware that "list" has a very special meaning in other programming languages. It would be mutch better to call it "collection" for example.
Remember: you use a programming language that enables you all options of OOP.
Use a class instead of an array and make your class traversable like an array. E.g.:
class orderCollection implements ArrayIterator
Or if you want to store the internal objects on different levels within an multi dimensional array/object structure:
class orderCollection implements RecursiveArrayIterator
This solution replaces your array by an object of type "orderCollection", but do not enable code completion within your IDE so far. Okay. Next step:
Implement the methods that are introduced by the interface with docblocks - particular:
/**
* [...]
* @return Order
*/
orderCollection::current()
/**
* [...]
* @return integer E.g. database identifier of the order
*/
orderCollection::key()
/**
* [...]
* @return Order
*/
orderCollection::offsetGet()
Do not forget to use type hinting for:
orderCollection::append(Order $order)
orderCollection::offsetSet(Order $order)
This solution stops introducing a lot of:
/** @var $key ... */
/** @var $value ... */
all over your code files (e.g. within loops), as Zahymaka confirmed with her/his answer. Your API user is not forced to introduce that docblocks, to have code completion. To have @return on only one place reduces the redundancy (@var) as mutch as possible. Sprinkle "docBlocks with @var" would make your code worst readable.
Finaly you are done. Looks hard to achive? Looks like taking a sledgehammer to crack a nut? Not realy, since you are familiar with that interfaces and with clean code. Remember: your source code is written once / read many.
If code completion of your IDE do not work with this approach, switch to a better one (e.g. IntelliJ IDEA, PhpStorm, Netbeans) or file a feature request on the issue tracker of your IDE producer.
Thanks to Christian Weiss (from Germany) for being my trainer and for teaching me such a great stuff. PS: Meet me and him on XING.