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