This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 197847 - No class methods/properties recognition on dynamic class instances creation
Summary: No class methods/properties recognition on dynamic class instances creation
Status: NEW
Alias: None
Product: php
Classification: Unclassified
Component: Editor (show other bugs)
Version: 7.0
Hardware: All All
: P2 normal (vote)
Assignee: Ondrej Brejla
Depends on:
Reported: 2011-04-18 19:21 UTC by fernandojmartin
Modified: 2012-04-24 14:56 UTC (History)
0 users

See Also:
Exception Reporter:

Test code for the mentioned issue (535 bytes, application/octet-stream)
2011-04-18 19:22 UTC, fernandojmartin

Note You need to log in before you can comment on or make changes to this bug.
Description fernandojmartin 2011-04-18 19:21:24 UTC
The autocomplete / suggestion feature doesn't works on dynamically created instances of a class.

See code below:


class Test {
    public $status;
    public $is_on;

    function foo(){
        // do something

function bar(){
    return new Test();

        [$status  |
        |$is_on   |
        |foo()    ]


 * Function baz
 * @param string the class name
 * @return instance_of class name
function baz($my_class){
    return new $my_class;

$t = baz('Test');
        [ No suggestions ]


Even tried to PHPDoc the baz() function as a pssible hint for NB but didn't work either.
Tried on NB 7.0 RC2 (usually working with 6.9)

There is a framework that's gaining some popularity in which / with I'm going to work, and since it's written most in this way the suggestion feature turns completely unuseful and NB works more like Notepad++ than an IDE.
The framework is "Agile Toolkit". Just in case you want to see the code, here is it:

I'de love to see support for this scenario in the definitive 7.0 version or ASAP.
Comment 1 fernandojmartin 2011-04-18 19:22:04 UTC
Created attachment 107821 [details]
Test code for the mentioned issue
Comment 2 fernandojmartin 2011-04-18 20:19:48 UTC

 * Function baz
 * @param string the class name
 * @return Test
function baz($my_class){
    return new $my_class;

$t = baz('Test');

This time it correctly parsed the Class methods and properties. However, if it's going to be creating instances dinamycally I can't rely on the PHPDoc.
Please see:

BTW, in this way doesn't works:

* @return $myclass
-> [ No suggestions ]
Comment 3 Petr Pisl 2011-04-19 10:50:15 UTC
This is not easy to support and it's almost impossible to find the right type. What happen when you will have:

function baz($my_class){
    $my_class = $namespace . '\' . $my_class
    return new $my_class;

or something like this, where the name of class is composed through an algorithm, which is in the most cases? NetBeans can not predict the values of variables.

In the code you can always use @var tag helper like this:


class Test {
    public $status;
    public $is_on;

    function foo(){
        // do something

function bar($name){
    return new $name;

/* @var $x Test */

The comment /* @var $x Test */ is saying that from this line the $x is threated as an instance of Test class. 

You can read more here

I can extend type resolving for case that you mentined, but I'm afraid that it will not work in the reality.
Comment 4 fernandojmartin 2011-04-19 13:53:41 UTC
Hi Petr.

Glad you gave me that guideness and indeed it does what I expected from the test code.

I can apply that approach to new fresh code I'm going to write. 
However, since I'm implementing the aforementioned framework (I hope you had the chance to look at it), and across different methods and classes new instances are created this way it would be REALLY helpful to not just rely on the vdoc feature (even, as I said, it really does what's expected).

If not possible then I should start documenting the whole framework and I can't imagine a way to make it flexible.
I mean, when the steps from the variable instantiation are far away than just 1 function call, something like this:

$b->js('click')->univ()->dialogURL('Sample',$this->api->getDestinationURL('./subpage'), array('width'=>1000));

This will produce an HTML button with an action bound to the click event. (

Method chaining is one of the greatest abilities of this framework and why I loved it almost instantly, but if is not possible for NB to find the declaration or suggest me methods/properties it will be hard (since I'm pretty new to it).

I hope you can do something about this for the next release. Again, it would be REALLY HELPFUL!


PS: Sorry for reporting as a BUG. Now I know it's clearly an enhancement.
Comment 5 Petr Pisl 2011-04-19 16:03:13 UTC
In the example like:

$button = $b->js('click')->univ()->dialogURL('Sample',$this->api->getDestinationURL('./subpage'),array('width'=>1000));

NetBeans should be able to recognized the type of $button if the return types are known for all methods in the chain. 

But this has also one performance impact. The finding return types of a method (if the return type is not defined through the php doc) require scanning the method body that can be slow in the case of long chain.
Comment 6 romaninsh 2011-04-19 16:15:44 UTC
Hi Petr.

To introduce myself, I'm the lead contributor of Agile Toolkit. We have a stable branch of Agile Toolkit but are also working on development copy and are focusing on code overhaul. 

We are very interested in helping you out by structuring the code and comments in such a way to make NetBeans parse it easier. I would gladly accept any suggestions you have and make them into our development release.

The biggest issue with the structure and code hinting is - all objects are cerated through "add"method

The class name is passed as 1st argument, but I suppose for IDE it's difficult to link it to the return type. In general we can assume that add() returns "AbstractObject" descendant, but unfortunately properties added in that descendant can't be accessed. 

If it would be any other language, I would write:

class *Form form = this->add('Form');

but I do not know how to do that in PHP. We also discussed possibility of dropping add() method, and it would be a too fundamental change destroying a core strength of the framework.

Any suggestions on how to make a compliant code are highly welcome.
Comment 7 fernandojmartin 2011-04-19 18:28:14 UTC
Being frank I still haven't tried the button example, however I'm writing a pretty simpler code:

//-- F O R M ---------------------------------------
    /* @var $f Form */
    $f->addField('line','first_name')->...[ No suggestions ];

In that way NB recognized the methods of $f, however isn't recognizing the upcoming, which could be "validateNotNull" and others, related to the field type being returned.

For instance:
    ->validateField('filter_var($this->get(), FILTER_VALIDATE_EMAIL)');

Of course I know this could have a huge performance impact and depending also on the size of the framework.
I believe that making optional (default OFF) the "deeper code parse - class eploring" would allow some people (like me, that really need that help from NB *AND* also have a very powerful box) to get the needed behavior.

What do you think?