Hi, I wouldn't mind if we weighted the pros/cons of the current solution against the initial proposition now that we had nearly 1 year to experience with the way it is now.
I really feel that the current way is something that we will regret later. And as of which solution to adopt, either always-forward or parent::/self:: forward, I believe they're both acceptable. Regards On Tue, Jul 8, 2008 at 4:17 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote: > Hi Mike, > > Yes. It was the initial proposal that was quite consistent. > > With current proposal we can call the same static method from the same > context with different behavior parent::foo(), self::foo(), A::foo(). > > I didn't get why can I call parent's method, but cannot call "self" or > grand-parent's method (with the same behavior). > > Thanks. Dmitry. > > > > > Mike Lively wrote: >> ---------- Forwarded message ---------- >> From: Mike Lively <[EMAIL PROTECTED]> >> Date: Tue, Jul 8, 2008 at 6:23 AM >> Subject: Re: [PHP-DEV] Re: parent:: forwarding >> To: Dmitry Stogov <[EMAIL PROTECTED]> >> >> >> >> >> On Tue, Jul 8, 2008 at 4:39 AM, Dmitry Stogov <[EMAIL PROTECTED]> wrote: >> >>> Each call to static method of parent class (it doesn't mater if it was >>> done using parent:: or something else) assumes forwarding of called >>> context. >>> >> >> Isn't this what the original LSB patches did and it was determined that >> letting everything forward was a bad idea? >> >> http://marc.info/?l=php-internals&m=118995456612295&w=2 >> >> The idea now is that we need a combination. static class names don't forward >> called context but parent:: does. If I could only choose between always >> forwarding called context and never forwarding called context (for parent:: >> and class names) I would rather always forward so this wouldn't be the end >> of the world for me, but I do believe the mixture is a more flexible way of >> handling things. >> >> On a different note, is that functionality introduced by the patch you don't >> like or is it the specific implementation? Is there a better way to >> implement it and retain the functionality it introduces? (for my own >> benefit) >> >> -Mike Lively >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
