Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23340
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <1771237045.20060514011813@marcus-boerger.de>
References: <785810036.20060511193536@ionzoft.com> <31.5F.19568.BD084644@pb1.pair.com> <4465FBED.8070205@php.net> <CB.8E.19568.30B26644@pb1.pair.com> <1771237045.20060514011813@marcus-boerger.de>
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <9ee13f5af8fe7e0171dfe66c7e23cb31@procata.com>
Content-Transfer-Encoding: 7bit
Cc: 'PHP-DEV' internals <internals@lists.php.net>
Date: Sun, 14 May 2006 00:24:33 -0400
To: Marcus Boerger <helly@php.net>
Subject: Re: [PHP-DEV] Re: private, protected, readonly, public
From: jeff@procata.com (Jeff Moore)


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