NuSphere Forums Forum Index
NuSphere Forums
Reply to topic
CodeInsight doesn't recognize class variables.


Joined: 11 Mar 2011
Posts: 11
Reply with quote
CodeInsight doesn't recognize and doesn't auto-complete class variables, like this:
Code:

class Test
{
  public function foo()
  {
    $this->bar = 123;

    if ($this->bar)
    {
      echo $this->bar;
    }
  }
}


...If I CTRL+Space after the second "if ($this->" fragment, nothing happens.

Although, if I add "public $bar;" to the class's definition, it works again, but in my case this is not enough, because the famous framework I use (Symfony) executes the specific class's method, then it gathers object's internal variables and passes them to the template engine. What this means is that I simply have to live without auto-completion in my classes. Or... may be NuSpehre developers can update their CodeInsight to watch and auto-complete $this->yadayada style variables correctly.
View user's profileFind all posts by drummerSend private message
Guru master

Joined: 24 Jul 2009
Posts: 737
Reply with quote
Bearing in mind that your Test class is not based on another class (eg does not extend another class) how can $this have a property called $bar? It is a complete encapsulated class.

If another class extends your Test class, then it is correct that $bar is not shown by CodeInsight, because that property belongs to the other class.

For example, this works fine in PhpED even if AnotherClass is in a separate code file:

Code:
class AnotherClass {
  protected $bar;
}

class Test extends AnotherClass {
  protected $hello;
  public function foo() {
    $this->bar = 123;
    if ($this->bar) {
      echo $this->bar;
    }
  }
}


The Test class can see $bar but AnotherClass cannot see $hello, and that is correct.
View user's profileFind all posts by plugnplaySend private message


Joined: 11 Mar 2011
Posts: 11
Reply with quote
Well, I see you're comming from Delphi-like environment, because everything had to be defined there.

See, in PHP we can do just like in the following example, and it is not that I am lazy person to define class variables explicitly, but because sometimes it is very convenient to get the resulting variable set from the class instance after executing some dynamically choosen method, then load another class dynamically, and pass variables to it's instance. How else would it be possible to create class variables dynamically? You may ask why is this needed and how is this object-oriented, but that's another question. Here is some explanation: w_w_w.hiteshagrawal.com/php/php5-tutorial-not-pure-object-oriented-programming-approach

And here is the perfectly legal PHP5 example:

Code:

class myClass
{
  public function doSomething()
  {
    $this->variableA = 'valueA';
    $this->variableB = 'valueB';
  }
}

$instance = new myClass();
$instance->doSomething();

$classVars = get_object_vars($instance);

var_dump($classVars);


Guess what will be on the output? Right, the array with two keys and two values. These became public variables automatically. Interesting to note that PhpED does highlight references to the same class variables (like $this->foo), but does not auto-complete them. This is a bug.
View user's profileFind all posts by drummerSend private message
Guru master

Joined: 24 Jul 2009
Posts: 737
Reply with quote
No, I'm not coming from a Delphi-like environment.

PhpED needs hints to know what to provide in CodeInsight at design-time and using those class level variables gives it those hints. What you get from a run-time analysis of an object (get_object_vars) does not necessarily have any bearing on what PhpED can get from a class at design-time. You can define variables using something like:

Code:
$var = 'te' . 'st';
$this->$var = 123;
echo $this->test;


And get_object_vars will show that just fine, but PhpED doesn't stand a chance with CodeInsight.

In your original post you seemed to suggest that $bar was already defined against the class somewhere (you showed $this->bar and said $bar came from Symfony) but without your Test class inheriting something else, there is nowhere for $bar to come from. Maybe your code sample was incomplete?

The usage of $this->bar within foo() can be assumed to have defined a variable and I guess in the absence of any other definition for $bar, maybe PhpED could also have assumed that and added it to CodeInsight. I don't personally consider it a bug, because I think it is highlighting an inadequacy in my coding technique. In that situation, if you had another function within the class that was just reading the value for $this->bar would you also expect CodeInsight? Technically it might be undefined within the class if foo() had not yet been called. So I know I should be considering adding the variable at class level and giving it a known initial value.

Just because PHP is in many respects 'lazy' doesn't mean you shouldn't define your class level variables as var/protected/public/etc. Many of the frameworks do define their class level variables like this, often complete with PHPDoc hints. As a third-party reading other peoples code I certainly appreciate such code hints, as I'm sure PhpED does also.
View user's profileFind all posts by plugnplaySend private message


Joined: 11 Mar 2011
Posts: 11
Reply with quote
Of course I do not expect PhpED to magically discover variables defined in the way you mentioned and showed in example. I only expect one case, which is simple and straight forward and which works like any other usual function-scope variable:
Code:

class myClass
{
  public function myFunction()
  {
    $this->myVar = 123;
    echo $this->myVar;
  }
}


Talking about coding techniques...
I wanted to show you a very reasonable usage of this, but then... this would be long and off-topic.

I am by the way strictly against PhpED supporting specific and non-standard stuff like framework-specific approaches. That is why I dislike many other IDEs. But I vote for PhpED supporting things which are natural, easy implemented and officially supported by PHP itself.

I marked places where I disagree with you:
Quote:
I don't personally consider it a bug, because I think it is highlighting an inadequacy in my coding technique.


Of course, every PHP IDE is personal, because these are created by people. But implying coding techniques AND at the same time denying another techniques (which are EASY to implement and which are supported by PHP) - this I would not accept as good.
View user's profileFind all posts by drummerSend private message
Guru master

Joined: 24 Jul 2009
Posts: 737
Reply with quote
I certainly agree with you that it is a valid way of using class level variables and I'm certainly not against PhpED supporting CodeInsight for them.

However, with a lack of tools in PhpED to inform about things like uninitialised variables, it would be something that I would prefer to be optional.

Now, my feature request would be support for highlighting of uninitialised variables. Very Happy
View user's profileFind all posts by plugnplaySend private message


Joined: 11 Mar 2011
Posts: 11
Reply with quote
Now I agree with you too.

For method-scope variables like $this->foo parsing, the CodeInsight should easily borrow logic from function-scope variable parsing.

Like this:
1) if there is "$this->foo" inside a method of class;
2) if there is no declaration of such variable in the hierarchy of class,
... treat this variable exactly as local variable.
View user's profileFind all posts by drummerSend private message
CodeInsight doesn't recognize class variables.
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 5 Hours  
Page 1 of 1  

  
  
 Reply to topic