Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23575
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <Pine.LNX.4.64.0605180021330.16412@mail.zend.com>
References: <785810036.20060511193536@ionzoft.com> <44647B7A.2070301@php.net> <932738738.20060513112734@marcus-boerger.de> <837405862.20060513223403@ionzoft.com> <36828701.20060514110529@marcus-boerger.de> <31269879.20060514221212@marcus-boerger.de> <1327845846.20060514222154@marcus-boerger.de> <1562034641.20060516203354@marcus-boerger.de> <7.0.1.0.2.20060516235201.090f10a8@zend.com> <7.0.1.0.2.20060516142654.02c78380@zend.com> <596643859.20060516233753@marcus-boerger.de> <7.0.1.0.2.20060516144030.039abe98@zend.com> <1531743211.20060516234945@marcus-boerger.de> <1014418169.20060516181322@ionzoft.com> <1677590447.20060517002135@marcus-boerger.de> <446A5B52.9060001@cschneid.com> <27079878.20060516191743@ionzoft.com> <446A601A.8010205@vocalspace.com> <f37b7981bd663f536ab158423df934a7@procata.com> <Pine.LNX.4.64.0605180021330.16412@mail.zend.com>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <1ad041100c1198a4cdca80eebec62f9e@procata.com>
Content-Transfer-Encoding: 7bit
Cc: internals@lists.php.net
Date: Thu, 18 May 2006 21:59:37 -0400
To: Stanislav Malyshev <stas@zend.com>
Subject: Re: [PHP-DEV] private, protected, readonly, public
From: jeff@procata.com (Jeff Moore)

Hello Stanislav,

On May 17, 2006, at 5:25 PM, Stanislav Malyshev wrote:

> JM>>individual properties, just as you can in Java, C#, Ruby, Delphi,
> JM>>Python, Visual Basic, Objective C, Smalltalk, and sometimes C++.  
> (To
> JM>>the best of my knowledge.)  Read only is a special case of this
> JM>>capability.
>
> This would be, however, yet another level of complexity added to the
> language...

I feel that it is __get and __set that are complicated.  Which is more 
complicated?

class Shape {
     protected $_dimension;

     function __get($name) {
         switch ($name) {
             case 'dimension':
                 return $this->_dimension;
         }
     }

     function __set($name, $value) {
         switch ($name) {
             case 'dimension':
                 if ($value < 0) {
                     throw new Exception('Negative dimension.');
                 }
                 $this->_dimension = $value;
         }
     }
}

Or

class Shape {
     protected $_dimension;
     property $dimension read $_dimension write setDimension();

     function setDimension($value) {
         if ($value < 0) {
             throw new Exception('Negative dimension.');
         }
         $this->_dimension = $value;
     }
}

I'm just using the Delphi syntax here because its what I know.  I don't 
want to get hung up on exact syntax.  Split visibility for simple 
properties could be implemented with the same syntax:

property $foo public read protected write;

In many ways I feel this is more understandable than readonly/readable.

In this syntax, visibility could be in any of three places:

[ visibility ] property $name [ visibility ] read [source]  
[[visibility] write [source]];

The visibility declaration for the accessor overrides the visibility 
for the property.

> JM>>2. __get/__set is slow.  (In the best case: about 10x slower than 
> simple
> JM>>property, 3x slower than an accessor method call)
>
> Slow as opposed to calling different function for different properties,
> adding additional lookups on each access?

Lets look at the performance cases.

Current property performance in relative units:

  100% : $obj->foo;
  385% : function getFoo() { return $this->_foo; }
1050% : function __get($name) { switch ($name) { case 'foo': return 
$this->_foo;}}  // first case is best case scenario


property $foo public read protected write;

I presume this could be written to perform the same as any simple 
property access?


property $foo read getFoo() write setFoo();
property $foo read getFoo() protected write setFoo();

No $name parameter.  No switch.  No guard?
I presume this would perform the same as a method call plus a property 
access, 100%+385% = 485%?
Yes, this might be 5 times slower than a simple property, but when you 
have to call a function, you have to call a function.  It might still 
be twice as fast as __get.


public property $foo read $_foo write setFoo();

If this could be implemented by aliasing $foo to $_foo, it would 
probably be about the same as two property accesses?  Half the speed of 
a simple property access, but five times faster than the best case 
scenario with __get?


While something like this may be complicated to implement internally 
(zend_property_info gets more fields), I fail to see the downside from 
the user's perspective.  Less code.  Faster code.  Explicit declaration 
instead of magic.  Autocompletion, PHPDoc & doc comments work.  
Reflection works.

I just think that split read/write visibility should be implemented as 
part of a more comprehensive property solution, or at the very least in 
a way that a more comprehensive solution could be implemented later.

Best Regards,

Jeff