On Wed, Jan 23, 2013 at 2:07 PM, Clint Priest <cpri...@zerocue.com> wrote:
>
> On 1/23/2013 1:00 PM, Marco Pivetta wrote:
>>
>>
>> Actually, having the properties shown even if virtual allows us to access
>> them in a reflection-ish manner without doing dangerous assumptions like
>> "does the setter/getter exist"?
>>
>> The fact that the property is virtual is very useful, even though in
>> dumping it doesn't show any value. I don't see any radical difference in
>> debugging or ease of use in general.
>> Actually, doing the same things with magic getters/setters would probably
>> imply having to think more about the trace we want to follow when analyzing
>> our bugs. It is just a matter of being aware of new setter/getters (that are
>> anyway in our trace).
>>
>
> If you stop and think about it, the current accessors are identical in
> functionality to defining a private variable for every __get().
>
> So these two sets of code work and act identically:
>
> class Foo {
> private $bar;
> public __get($name) {
> if($name == 'bar')
> return $this->bar;
> }
> public __set($name, $value) {
> if($name == 'bar')
> $this->bar = $value;
> }
> public __isset($name) {
> if($name == 'bar')
> return isset($this->bar);
> }
> public __unset($name) {
> if($name == 'bar')
> unset($this->bar);
> }
> }
>
> -- OR --
>
> class Foo {
> public $bar { get; set; }
> }
>
> Except in the first case, you have to look at four sections of code to find
> "everything that applies to bar" and if you add 5 or 6 more dynamic
> properties, you have 4 huge switch statements, again with all the code split
> up everywhere.
>
> With Property Accessors, it's all right there. This of course is a very
> simple case, if you actually USE the dynamic nature of __get(), etc then
> you've got a ton more code.
Let's not forget that all __get and __set would have save visibility
unless you manually controlled that which means more coding. Yay!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
