There is currently no parent::get(), parent::set() capability. The RFC has no mention of being able to call the parent accessor and so I have not explored that possibility. It would be a nice feature for just such a purpose.
-----Original Message----- From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com] Sent: Sunday, December 11, 2011 10:35 PM To: Will Fitch Cc: Clint M Priest; Pierre Joye; internals@lists.php.net Subject: Re: [PHP-DEV] Accessors v2 Patch hi Will, That's what I've been thinking about. I have a special necessity to overload a class in a Proxy implementation (an instance that wraps a real Entity), demanding the load when any getter is active. This implementation seems to fit perfectly my needs, while still be cleaning. I wonder if the user have already implemented a getter in this approach, how can I overload this one? Example: class Foo { protected $name { get { return $this->name; } set { $this->name = $value; } } // ... } class FooProxy extends Foo { protected $name { get { $this->__load(); parent::get(); } set { $this->__load(); parent::set($value); } } // ... } How would it act in this situation? Cheers, On Sun, Dec 11, 2011 at 10:18 PM, Will Fitch <will.fi...@gmail.com> wrote: > This approach, in theory, is an interceptor itself. Most use-cases around > this approach will be changing or augmenting an existing property that is not > public. If you wanted to modify this interception, you'd need to extend the > class using it and redefine the getter and/or setter. > > > On Dec 11, 2011, at 10:02 PM, guilhermebla...@gmail.com wrote: > >> I have just one question, partially unrelated. >> >> How can I make something similar to Interceptors of Java according to >> your approach? >> For those that have no idea, interceptors is a way to intercept >> get/set of a property inside the class and act under this >> circumstance. >> >> []s, >> >> On Sun, Dec 11, 2011 at 8:01 PM, Clint M Priest <cpri...@zerocue.com> wrote: >>> To be complete I should probably add something to the reflection system as >>> well. At present the getters/setters would show up as functions. >>> >>> What would be preferable? >>> 1) Show up as regular functions and let users fend for themselves? >>> 2) Hide from getMethods() and: >>> 2.1) Provide getAccessors() - Probably returning a new >>> ReflectionPropertyAccessor class? >>> 2.2) Provide getGetters(), getSetters() >>> 3) Modify ReflectionProperty to include hasGetter() and hasSetter() >>> >>> Comments? >>> >>> -----Original Message----- >>> From: Pierre Joye [mailto:pierre....@gmail.com] >>> Sent: Sunday, December 11, 2011 6:47 PM >>> To: Clint M Priest >>> Cc: internals@lists.php.net >>> Subject: Re: [PHP-DEV] Accessors v2 Patch >>> >>> oh right, I missed them. Yes, so it is covered as well :) >>> >>> On Mon, Dec 12, 2011 at 1:42 AM, Clint M Priest <cpri...@zerocue.com> wrote: >>>> There are already two tests against private read and private write, should >>>> I add two for protected as well? >>> >>> Cheers, >>> -- >>> Pierre >>> >>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, >>> visit: http://www.php.net/unsub.php >>> >> >> >> >> -- >> Guilherme Blanco >> MSN: guilhermebla...@hotmail.com >> GTalk: guilhermeblanco >> Toronto - ON/Canada >> >> -- >> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, >> visit: http://www.php.net/unsub.php >> > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
