On May 13, 2006, at 7:18 PM, Marcus Boerger wrote:
hehe, maybe confused with delphi or borlands c++ additons? Speaking of
which before we add 'readonly' we should go for full property support but
on the other hand that might be a little bit too much until php is used
with code generators and gui designers where code inspectors execute and
manipulate source/code while developing.
Hi Marcus,
Full property support is high on my wishlist for 6.0. I was a Delphi programmer for 5 years and miss properties. C#, Ruby, and Java all have built in property support with accessor methods, or at least a single standard implementation that all the tools can get behind. __get and __set leave you in complete limbo for both source code and reflection based tools. I think the language support has to come before the tools.
I think this can be implemented by adding a getter and setter field to zend_property_info, then checking for it in zend_std_read_property, etc. Although, I'm sure there's more to it than that. Such an implementation would probably be 3 to 4 times faster than __get(). No switch, no $name parameter, perhaps no guard logic. Checking for a getter or setter in zend_property_info would be a fast boolean test on a data structure thats already available, so I believe there would be little overhead.
Here are a few use cases and syntax suggestions...
A. Declaring a property with accessor methods:
public $foo read getFoo write setFoo;
B. Read only property with accessor method could be declared:
public $foo read getFoo;
C. A shortcut notation could automatically generate the accessor method based on another property:
public $foo read $_foo;
// internally generated method ala C# property implementation:
// public function __get_foo() { return $this->$_foo; }
D. Similar to read only, you could have split visibility, for example, a public getter and a protected setter:
public $foo read getFoo write protected setFoo; // Handy use case, not crazy about this syntax
public function getFoo() { return $this->_foo; }
protected function setFoo($value) { $this->_foo = $value }
E. To avoid warnings, declare the internal storage, too:
public $foo read $_foo write setFoo, protected $_foo;
public $foo read $_foo, protected $_foo; // readonly
F. Properties with accessor methods cannot be directly initialized. Their internal storage can, however:
public $foo read $_foo write setFoo, protected $_foo = 'bar';
G. calling unset() on a property with accessor methods could call the setter with NULL.
H. calling isset() on a property with accessor methods returns FALSE if the property does not exist, otherwise calls the getter and compares against NULL for compatibility purposes. (?)
I. calling property_exists() on a property with accessor methods would always return TRUE.
J. The setter and getter could be inspected via ReflectionProperty.
K. Unlike __get, subclass property definitions could override the parent declarations:
class Foo { public $prop; }
class Bar extends Foo { public $prop read getProp write setProp; ... }
L. An abstract class need not declare the actual accessor methods, they could be added as abstract by default:
abstract class Bar { public $foo read getFoo write setFoo; }
Just a few thoughts. I am sure there are other possibilities for the same use cases.
Best Regards,
Jeff