Re: Accessors v2 Patch
| From: | guilhermeblanco@gmail.com | Date: | Mon, 12 Dec 2011 04:34:34 +0000 |
| Subject: | Re: Accessors v2 Patch | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-56881@lists.php.net to get a copy of this message | ||
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.fitch@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, guilhermeblanco@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 <cpriest@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.php@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 <cpriest@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: guilhermeblanco@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: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada