|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2000-05-26 15:06 UTC] Jim dot Moores at quickstone dot com
Could you consider making the class member namespace available to member functions? I'm sick of typing: $this->foo() for every variable that is a class member. I did have a look at the code myself, but, as always with compilers, it's difficult to know where to start (and what the knock on effects of your changes will be). So I thought I'd beg you guys. Go on. You know you want to. :) Thanks for listening, Jim Moores. PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Nov 16 07:00:01 2025 UTC |
There are several options: 1) When you come across an identifier you haven't seen before - see if it is already declared as a symbol in the containing class and assume it refer's to that if it is. This has the problem that it is not compatible with previous versions of PHP. 2) Make it compulsary to declare local variables, then use the normal strategy, which is to treat as a local variable if one is declared, else treat as a class variable, else treat as a global. This is also not backwards compatible. 3) Introduce a new keyword - similar in concept to global - that declares an identifier as refering to a member: the keyword `member' would be a good candidate - this would also be backwards compatible. The disadvantage of this scheme is that it'd be a pain (but probably not as much as $this). 4) Introduce some sort of pragma indicating to the compiler that this function is aware that you are using strategy 1) or 2). For example you could delcare functions: member function get_property($x) { ... } or come up with a replacement new keyword: method get_property($x) { ... } that has this different property - its better to declare variables anyway :) I think option 4) is most desirable, and option 3) is the easiest to do. I doubt you guys would even consider breaking compatibility. Option 4 also gives you the option of introducing other OO things such as public/private/package if you like that sort of thing. And you can still support all the legacy code.