Viewed   471 times

So, in PHPDoc one can specify @var above the member variable declaration to hint at its type. Then an IDE, for ex. PHPEd, will know what type of object it's working with and will be able to provide a code insight for that variable.

  class Test
    /** @var SomeObj */
    private $someObjInstance;

This works great until I need to do the same to an array of objects to be able to get a proper hint when I iterate through those objects later on.

So, is there a way to declare a PHPDoc tag to specify that the member variable is an array of SomeObjs? @var array is not enough, and @var array(SomeObj) doesn't seem to be valid, for example.




/* @var $objs Test[] */
foreach ($objs as $obj) {
    // Typehinting will occur after typing $obj->

when typehinting inline variables, and

class A {
    /** @var Test[] */
    private $items;

for class properties.

Previous answer from '09 when PHPDoc (and IDEs like Zend Studio and Netbeans) didn't have that option:

The best you can do is say,

foreach ($Objs as $Obj)
    /* @var $Obj Test */
    // You should be able to get hinting after the preceding line if you type $Obj->

I do that a lot in Zend Studio. Don't know about other editors, but it ought to work.

Sunday, August 14, 2022

Easy as pie:

Open Eclipse and go to Help-> Software Updates-> Find and Install Select "Search for new features to install" and click "Next" Create a New Remote Site with the following details:

Name: PDT


Get the latest above mentioned URLfrom -

Check the PDT box and click "Next" to start the installation

Hope it helps

Friday, September 16, 2022

It's not included.

If it's not included, do you have Any clue why it was not included when type hinting was added?

With the current array implementation, it would require checking all array elements at runtime, because the array itself contains no type information.

It has actually already been proposed for PHP 5.6 but rejected: RFC "arrayof" - interestingly not because of performance issues which turned out to be neglible, but because there was no agreement in how exactly it should be implemented. There was also the objection that it is incomplete without scalar type hints. If you are interested in the whole discussion, read it in the mailing list archive.

IMHO array type hints would provide most benefit together with typed arrays, and I'd love to see them implemented.

So maybe it's about time for a new RFC and to reopen this discussion.

Partial Workaround:

you can type hint variadic arguments and thus write the signature as

function findUserByAge(int $age, User ...$users) : array


findUserByAge(15, ...$userInput);

In this call, the argument $userInput will be "unpacked" into single variables, and in the method itself "packed" back into an array $users. Each item is validated to be of type User. $userInput can also be an iterator, it will be converted to an array.

Unfortunately there is no similar workaround for return types, and you can only use it for the last argument.

Friday, August 19, 2022

I think you're doing things a bit strange.

You already have all your information in an SVN repository, so why not take advantage of that?

You keep a working copy on your computer for development and testing. Save and commit your changes to SVN. On your server, do an SVN export (or checkout, with appropriate server rules to block web access to the .svn folders), and you're sweet!

----------------------         ------------         ---------------
| Local Working Copy |  <--->  | SVN Repo |  <--->  | Live server |
----------------------         ------------         ---------------

This means you never have to worry about FTP, or have to figure out which files have been changed locally and hence need to be updated.

Tuesday, December 27, 2022

Your problem is that you want to use type hints but you want this class itself to be able to take arguments of its own type.

The type hints PEP (0484) explains that you can use the string version of the type's name as a forward reference. The example there is of a Tree data structure which sounds remarkably similar to this OrgUnit one.

For example, this works:

class OrgUnit(object):

    def __init__(self,
                 an_org_name: str,
                 its_parent_org_unit: 'OrgUnit' = None

In Python 3.7, you will be able to activate postponed evaluation of annotations with from __future__ import annotations. This will automatically store annotations as strings instead of evaluating them, so you can do

from __future__ import annotations

class OrgUnit(object):
    def __init__(self,
                 an_org_name: str,
                 its_parent_org_unit: OrgUnit= None

This is scheduled to become the default in Python 4.0.

Saturday, September 10, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :