Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:17573 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97034 invoked by uid 1010); 7 Aug 2005 18:07:11 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 97019 invoked from network); 7 Aug 2005 18:07:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Aug 2005 18:07:11 -0000 X-Host-Fingerprint: 70.85.46.36 unknown Received: from ([70.85.46.36:47138] helo=prohost.org) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 0D/81-04646-ECD46F24 for ; Sun, 07 Aug 2005 14:07:10 -0400 Received: (qmail 11882 invoked from network); 7 Aug 2005 18:07:06 -0000 Received: from cpe00095beeab35-cm000f9f7d6664.cpe.net.cable.rogers.com (HELO ?192.168.1.5?) (69.196.31.219) by prohost.org with SMTP; 7 Aug 2005 18:07:06 -0000 Message-ID: <42F64DC8.2000205@prohost.org> Date: Sun, 07 Aug 2005 14:07:04 -0400 User-Agent: Mozilla Thunderbird 1.0 - [MOOX M3] (Windows/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derick Rethans , internals@lists.php.net References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Property Overloading RFC From: ilia@prohost.org (Ilia Alshanetsky) 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) Rather then adding abstract properties, why not simply document the possible values inside the doc comments ala: /** * @var abstract int Contains all X */ > 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). That's the whole concept behind the feature, if the values were known you may as well use clearly declared property and method names. > 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. How about adding a 3rd optional argument to __get and __set which would be an array of acceptable values for the "name" parameter? If there is a mismatch a standard warning message will be raised if this parameter was supplied. ilia