Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18196
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <Pine.LNX.4.62.0508021457590.2808@localhost>
References: <Pine.LNX.4.62.0508021457590.2808@localhost>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <9a92bfda7c2386d7fb84f54aa171d465@procata.com>
Content-Transfer-Encoding: 7bit
Cc: PHP Developers Mailing List <internals@lists.php.net>
Date: Wed, 17 Aug 2005 13:19:37 -0400
To: Derick Rethans <dr@ez.no>
Subject: Re: [PHP-DEV] Property Overloading RFC
From: jeff@procata.com (Jeff Moore)


On Aug 2, 2005, at 9:05 AM, Derick Rethans wrote:

> Problems:
> 1. There is no way to document the 'virtual' properties with any of  
> the existing
>    documentation tools (such as phpdoc and doxygen)

This sounds like a tool problem, not a language problem.

> 2. There is no way how the magic methods know if a specific 'virtual'  
> property
>    exists or not as those properties are not declared usually - unless  
> you
>    define an array with property names as a class constant (which is  
> not
>    allowed either).

Sometimes you just want to know if a single property exists and  
sometimes you want to know all the properties.  There are cases where  
generating the full list of properties may be overly expensive (ORM  
with inheritance).

__has_property($name)
__get_property_list()

Note that some properties may be read only and some might be write  
only, so perhaps incorporating intended use into the API:

__has_readable_property($name)
__has_writable_property($name)
__get_readable_properties()
__get_writable_properties();

> 3. There is no way for the magic methods to return a meaningfull error  
> when a
>    property doesn't "exist". Of course it is possible to throw an  
> error with
>    "trigger_error" or "throw" in case a property doesn't "exist" in a  
> specific
>    class, but the file and line numbers would not match the actually  
> get/set
>    action. debug_backtrace() can be used to retrieve the correct file  
> and line,
>    but as you have to do this for every class where you want to use  
> setters and
>    getters *and* you have to implement your own error message rendering
>    function this is not really a suitable option either.

I would rather see exceptions used instead of changing the established  
method signature of __get and __set.  What about defining a standard  
PropertyNotFound exception?



While on the topic, a little wishlisting.  i would like to see an  
accessor method search path, much like Objective C's KeyValueCoding:

http://developer.apple.com/documentation/Cocoa/Conceptual/ 
KeyValueCoding/index.html

so, this defines a read only virtual property:

class Square {
	function __get_area() {
		return $this->width*$this->length;
	}
}

echo $sq->area;

in this case, PHP would look for a __get_XXX method before calling the  
__get as a last resort fallback.  I'm  not attached to this particular  
syntax, but I think the KVC concept with an accessor method naming  
convention has proven worthwhile in Objective C.  KVC also has some  
interesting advanced features such as indexed properties, paths, change  
notification, and constraint enforcement.  KVC is worth emulating.