Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Fix inconsistencies in OO calls »

Fix inconsistencies in OO calls

php.internals

Etienne Kneuss

19 years ago
Hello, Currently, those are allowed: new $classname; classname::$methodname(); but those aren't: $classname::foo(); $classname::CONST; $classname::$member; Here is a patch for head that fixes those inconsistencies by extending the language parser to support such syntax: http://patches.colder.ch/Zend/dynamic_static_calls.patch?markup (patch also attached) Regards
-- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal

Johannes Schlueter

19 years ago
Hi Etienne, On Mon, 2007-07-30 at 22:27 +0200, Etienne Kneuss wrote:
> Hello, > > Currently, those are allowed: > > new $classname; > classname::$methodname(); > > but those aren't: > > $classname::foo(); > $classname::CONST; > $classname::$member; > > Here is a patch for head that fixes those inconsistencies by extending > the language parser to support such syntax:
thanks for this fix. Ilia, do you mind MFHing this fix before the next 5.2 release? Then I'd commit it within the next days. johannes

Andi Gutmans

19 years ago
This is not really a fix. When we worked on PHP 5 we deliberately decided to relax on all the weird dynamic constructs which didn't provide a lot of value for the majority of use-cases. Of course the Reflection API was going to be the way to do these dynamic things in future. It would also simplify the engine's code. The reason why those first constructs work were for BC reasons. We didn't want to break existing code but wanted to not add on top of this. While it may feel inconsistent I still prefer the existing path. Maybe for PHP 6 we can even make an E_STRICT message for the old way which refers you to the Reflection API? Andi
> -----Original Message----- > From: Johannes Schlüter [mailto:johannes@php.net] > Sent: Tuesday, July 31, 2007 4:57 AM > To: Etienne Kneuss > Cc: internals@lists.php.net; Ilia Alshanetsky > Subject: Re: [PHP-DEV] Fix inconsistencies in OO calls > > Hi Etienne, > > On Mon, 2007-07-30 at 22:27 +0200, Etienne Kneuss wrote: > > Hello, > > > > Currently, those are allowed: > > > > new $classname; > > classname::$methodname(); > > > > but those aren't: > > > > $classname::foo(); > > $classname::CONST; > > $classname::$member; > > > > Here is a patch for head that fixes those inconsistencies > by extending > > the language parser to support such syntax: > > thanks for this fix. > Ilia, do you mind MFHing this fix before the next 5.2 > release? Then I'd commit it within the next days. > > johannes > > > > http://patches.colder.ch/Zend/dynamic_static_calls.patch?marku
p (patch

Arnold Daniels

19 years ago
Hi all, Well I might not be one to speak, but I feel strongly about this, so will do it anyway. Personally I like the dynamic constructs, I use it all the time and would be devastated if it would disappear. This is for instance a piece of code of a project where I'm working on right now: $val = $this->bpl->{$setting}[$uid]; With the reflection api I would need to do: $refl = new ReflectionProperty(get_class($this->bpl), $setting); $arr = $refl->getValue($this->bpl); $val = $arr[$uid]; unset($refl, $val); ... right. I'm not sure which use cases ware contemplated, but all my projects have got a lot of these structures. Sure, you can use the reflection API or call_user_func() in many cases, but I think that it makes my code unreadable and bloated. And in some cases, since PHP doesn't require defining properties and methods in classes (__get()/__set()/__call(), ArrayObject, or just $obj->newprop=1), using the reflection API won't even work. For instance (also a real world example): $prop = (string)($sxml->$setting); // $sxml is a SimpleXmlElement. Anyway, isn't PHP about freedom? Anyone is free to use the reflection class if they think it is cleaner or in another way the right path. Having only one correct to do things way sounds more like Java to me, and actually the main reason why I don't write Java anymore. So personally I would love to see this patch included. I know already quite some places where it would make my code a lot simpler. Best regards, Arnold Andi Gutmans wrote:

Derick Rethans

19 years ago
On Wed, 1 Aug 2007, Andi Gutmans wrote:
> This is not really a fix. When we worked on PHP 5 we deliberately > decided to relax on all the weird dynamic constructs which didn't > provide a lot of value for the majority of use-cases. Of course the > Reflection API was going to be the way to do these dynamic things in > future. It would also simplify the engine's code. The reason why those > first constructs work were for BC reasons. We didn't want to break > existing code but wanted to not add on top of this. > > While it may feel inconsistent I still prefer the existing path. Maybe > for PHP 6 we can even make an E_STRICT message for the old way which > refers you to the Reflection API?
I think that'd be a bad idea. I don't see a problem with this patch at all, and why should people use reflection here? As you're always so much for BC, I find it strange that you're suggesting to remove something totally harmless and instead want people to force to use the slow Reflection API which is meant for introspection... Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Lukas Kahwe Smith

19 years ago
Derick Rethans wrote:
> On Wed, 1 Aug 2007, Andi Gutmans wrote: > >> This is not really a fix. When we worked on PHP 5 we deliberately >> decided to relax on all the weird dynamic constructs which didn't >> provide a lot of value for the majority of use-cases. Of course the >> Reflection API was going to be the way to do these dynamic things in >> future. It would also simplify the engine's code. The reason why those >> first constructs work were for BC reasons. We didn't want to break >> existing code but wanted to not add on top of this. >> >> While it may feel inconsistent I still prefer the existing path. Maybe >> for PHP 6 we can even make an E_STRICT message for the old way which >> refers you to the Reflection API? > > I think that'd be a bad idea. I don't see a problem with this patch at > all, and why should people use reflection here? As you're always so much > for BC, I find it strange that you're suggesting to remove something > totally harmless and instead want people to force to use the > slow Reflection API which is meant for introspection...
I agree its harmless and easy to learn. Moreover I do not see the benefit of using the Reflection API instead. @Andi: Could you explain to us why you think that this sort of thing should best be done through the Reflection API? regards, Lukas

Vesselin Kenashkov

19 years ago
I agree with Derick and Lukas. I find the ways this patch proviedes to be much more "natural" and easy to learn (I personally was in a desparate need for $classname::everything and also was wondering why it is not implemented, and then I found the Reflection). I'm just php developer, and I do not have experiance with other languages, but still I think the way it is implemented in the patch is the "natural" way to do it. And if Reflection is slower and meant for introspection why to use it for this. Is there any specific consideration for using Reflection for this? Or was there a discussion about this topic earlier (can somebody point me to it)? +1 for the patch. Vesselin Kenashkov On 8/2/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:

Sebastian Bergmann

19 years ago
Derick Rethans schrieb:
> I think that'd be a bad idea. I don't see a problem with this patch at > all, and why should people use reflection here? As you're always so much > for BC, I find it strange that you're suggesting to remove something > totally harmless and instead want people to force to use the > slow Reflection API which is meant for introspection.
I agree. The Reflection API is the "right tool for the job" when you are meta-programming (developing tools such as PHPUnit, for instance) but not when you are programming.
-- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

David Zülke

19 years ago
ACK. David Am 02.08.2007 um 11:36 schrieb Sebastian Bergmann:

Marcus Börger

19 years ago
Hello Sebastian, yep, you and Derick are right here. This is definitively a fix that should go in. Chinstrap just commit the stuff please. marcus Thursday, August 2, 2007, 11:36:54 AM, you wrote:
> Derick Rethans schrieb: >> I think that'd be a bad idea. I don't see a problem with this patch at >> all, and why should people use reflection here? As you're always so much >> for BC, I find it strange that you're suggesting to remove something >> totally harmless and instead want people to force to use the >> slow Reflection API which is meant for introspection.
> I agree. The Reflection API is the "right tool for the job" when you > are meta-programming (developing tools such as PHPUnit, for instance) > but not when you are programming.
> -- > Sebastian Bergmann http://sebastian-bergmann.de/ > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Best regards, Marcus

Andi Gutmans

19 years ago
Marcus, It'd be kind if you gave me chance to reply before you tell people to "just commit stuff". I'm just about to hop on a plane and will look at the patch again tomorrow. If people feel so strongly about it and the patch is decent (doesn't screw up common case and maintainability) I'm OK with it. It's not a big deal but being a bit more courteous wouldn't hurt you. Andi

Richard Lynch

19 years ago
I'll just chime in and say that I also find the current variable-substitution idiom more "natural" than using a Reflection class to look up a bunch of stuff... If it's gonna kill youse guys to keep it in there with some kind of code-maintenance nightmare, fine, kill it. But if not, having two ways to do the same thing is not necessarily a Bad Thing, and I think it's a Fine Thing in this case to have both OOP Reflection and a more "natural" way to do it. imho ymmv etc
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?