Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42F0325A.9070803@php.net>
Date: Tue, 02 Aug 2005 22:56:26 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Derick Rethans <dr@ez.no>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <Pine.LNX.4.62.0508021457590.2808@localhost>
In-Reply-To: <Pine.LNX.4.62.0508021457590.2808@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Property Overloading RFC
From: cellog@php.net (Greg Beaver)

Hi,

As for the first question of how to document virtual properties, I have 
been recommending that users do this textually inside the docblock for 
__get()/__set().  This is actually ideal in almost every case, as anyone 
using __get()/__set() for finite, concrete properties should almost 
definitely be instead using plain old properties.  I wonder if adding 
this language feature might be a bit too hopeful.  For instance, most 
implementations I have seen of __get()/__set() use them because it isn't 
possible to know the names of the variables in advance.  Simplexml and 
ext/soap are great examples of extensions that were they implemented in 
userspace would not be able to use the abstract/virtual keyword proposed 
because until the specific class is instantiated, one can't know what 
they will be working with.  The Savant template engine may use them for 
grabbing filtered variables in the future, another good example of "you 
must document this with prose, not with program syntax".

Having said this, if the proposal continues, I do have some suggestions.

2)

<?php
class Base
{
  	abstract public $x = 1;
  	
  	function __get($name)
  	{
  		if (!$this->isAbstract($name))) {
  			/* throw error */
  		}
  	}
}
?>

or

<?php
class Base
{
  	virtual public $x = 1;
  	
  	function __get($name)
  	{
  		if (!$this->isVirtual($name))) {
  			/* throw error */
  		}
  	}
}
?>

I prefer the 2nd, as it will not confuse with abstract classes (and it 
will definitely confuse users if we start mixing metaphors 
programmatically).

I also prefer $this-> to self:: as it will allow (as James Crumpton 
raised) inheritance without redefinition of __get()/__set().

> 
> - Problem 3 can be solved by:
>   * allowing optional by-ref parameters to the __set
>     and __get function, so that their signatures become:
> 
>     function __set($name, $value [, &$error] )
>     function __get($name [, &$error] )
> 
> 	If the parameter is not given things behave just like they do now -> __set
> 	and __get can not throw meaningful errors with the correct file/line of the
> 	conflicting statement
> 
> 	If the parameter is used in the function's declaration and is set to
> 	"false" when the __set or __get function returns, the engine can throw an
> 	error on the assignment line with the correct file/line combination. If
> 	it's set to "true" (or "null") then the engine should not throw any error.
> 
>   * Use a different __set and __get function for 'abstract' properties, then
>     the engine can already determine if you're doing something wrong before
>     executing the __set and __get methods.

It seems to me the best solution would be to allow error to be set to 
false or an exception object, which would be then thrown as if it was on 
the offending line.  This would allow the user to customize the error 
message as well as the line/file.

Greg