> 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; }
>
Yes, full property support would be nice. Though not to keen on that syntax,
but can't think of anything nicer as yet :)
Haxe ( http://www.haxe.org/ref#properties ) has something like
public $prop(getter, setter);
Where getter and setter can be a method name, null for not allowed, default for
basic accessor, which is less to type, but still not
that nice.
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
