Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17511
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 3 Aug 2005 19:08:42 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1541009668.20050803190842@marcus-boerger.de>
To: Greg Beaver <cellog@php.net>
Cc: Derick Rethans <dr@ez.no>,
	PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <42F0325A.9070803@php.net>
References: <Pine.LNX.4.62.0508021457590.2808@localhost>
	<42F0325A.9070803@php.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: Property Overloading RFC
From: helly@php.net (Marcus Boerger)

Hello Greg,

Wednesday, August 3, 2005, 4:56:26 AM, you wrote:

> 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".

How about lazy initialization? You cannot have a declared property for those
atm.

> 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).

You would need to add another keyword for no reason.

> I also prefer $this-> to self:: as it will allow (as James Crumpton 
> raised) inheritance without redefinition of __get()/__set().

I prefer here using property_is_virtual($this, $name).

>> 
>> - 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.

I suggested exceptions but they are not always acceptable and overcomplicate
many things too much and finally come with some danger.

Best regards,
 Marcus