Is there any way how can I write hint for code completioner that variable is array of some type of objects?

Example (montage showing what I mean):

+ 1

Similar feature request is already here: http://forum.nusphere.com/type-hinting-for-arrays-t5837.html

The problem is that there is no official syntax. Blizz thinks that the correct syntax is @var array(int => Component), but according to PHPLint (http://www.icosaedro.it/phplint/phpdoc.html#types) is the corrent syntax @var array[int]Component (this should be already supported by phpDocumentor).

+1

I'm totally for this!

+1

yes please.

+1

this feature is supported by v7:

@dmitri: seems awesome, but does not work foreach cycle.

will work in the next build (7020)

btw, did you know that iteractors (with known class returned by current()) are supported in foreach?

Wow, it's awesome.
Btw, there is little bug:

If you mean that it's not/should not be possible to read from [], that's checked in RUN-TIME.
Such errors are hard to capture at COMPILE-TIME.
The following code is perfectly-valid and works as expected.

Yes, you are right, I meant the missing index. However, it's better to suggest more than less Thanks for explanation.

It's because php grammar works this way.
It first gets test()[] tokens grouped and at this time it could raise an error telling that [] is not properly used, but it can't because it does not know how this group will be used -- f/e test()[] = 5; (WRITE access) whic is okay -- you return a reference to an array from the function then add new element to it, and in the other case it can't be correct when you try to call something test()[]->method() (READ access) assuming that the function returned array of object instances. To distinct these two cases (Read and Write access to the array), it's necessary either detect the problem at run-time (which is what was done in php), or add new set of rules to the grammar and does not allow [] to appear in LVAL, but it's not that trivial to do.