Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:18435 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90037 invoked by uid 1010); 25 Aug 2005 17:25:03 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 90021 invoked from network); 25 Aug 2005 17:25:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Aug 2005 17:25:02 -0000 X-Host-Fingerprint: 65.19.190.98 procata.com Linux 2.4/2.6 Received: from ([65.19.190.98:38483] helo=procata.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 14/4D-28235-CEEFD034 for ; Thu, 25 Aug 2005 13:25:01 -0400 Received: from 65.111.204.159 ([65.111.204.159]) by procata.com for ; Thu, 25 Aug 2005 10:24:49 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID: <7f5633f412777170ec4c73e541142228@procata.com> Content-Transfer-Encoding: 7bit Cc: Raymond Bosman , PHP Developers Mailing List , Jan Borsodi , Frederik Holljen , Tobias Schlitt Date: Thu, 25 Aug 2005 13:25:07 -0400 To: Derick Rethans X-Mailer: Apple Mail (2.622) Subject: Re: [PHP-DEV] Property Overloading RFC From: jeff@procata.com (Jeff Moore) On Aug 25, 2005, at 8:01 AM, Derick Rethans wrote: > On Tue, 2 Aug 2005, Derick Rethans wrote: > I updated the proposal: > http://files.derickrethans.nl/property_overloading.html #1) It seems to me that after declaring the property with the property keyword, the property isn't so virtual anymore. #2) I think this is a good idea, but aren't double underline methods reserved for those called by PHP itself. The example shows the user calling __have_prop(). Under what circumstances would php call __have_prop()? #3) I would rather see an exception based mechanism for this, but I'll concede that as unlikely, so i'll just suggest using the standard PHP boolean values. The proposal implies TRUE & NULL would be the same, which seems inconsistent.