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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
