CodeInsight doesn't recognize class variables. |
Guru master
|
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:
The Test class can see $bar but AnotherClass cannot see $hello, and that is correct. |
||||||||||||||
|
|
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:
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. |
||||||||||||||
|
Guru master
|
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:
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. |
||||||||||||||
|
|
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:
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:
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. |
||||||||||||||||
|
Guru master
|
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. |
||||||||||||
|
|
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. |
||||||||||||
|
CodeInsight doesn't recognize class variables. |
|
||
Content © NuSphere Corp., PHP IDE team
Powered by phpBB © phpBB Group, Design by phpBBStyles.com | Styles Database.
Powered by
Powered by phpBB © phpBB Group, Design by phpBBStyles.com | Styles Database.
Powered by