Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17543
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 4 Aug 2005 20:04:12 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <607465810.20050804200412@marcus-boerger.de>
To: boots <jayboots@yahoo.com>
Cc: internals@lists.php.net
In-Reply-To: <20050804042951.64930.qmail@web50802.mail.yahoo.com>
References: <20050804042951.64930.qmail@web50802.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Property Overloading RFC
From: helly@php.net (Marcus Boerger)

Hello boots,

Thursday, August 4, 2005, 6:29:51 AM, you wrote:

> 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)
>> 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).
>> 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.

> As far as introspection (points 1 and 2), would it be reasonable to
> allow __get/__set to be called without any parameters in which case
> they would be expected to optionally return an array or object
> designating the properties that they support? I know that this is
> somewhat magical but dynamic features are somewhat magical to begin
> with -- which is part of their charm.

To complicated and uses one thing to do two completley different things
which confuses everyone.

> FWIW, it would be nice if there was a way for __get/__set to support
> references.

Best regards,
 Marcus