Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:17503 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49867 invoked by uid 1010); 2 Aug 2005 19:06:36 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 49852 invoked from network); 2 Aug 2005 19:06:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2005 19:06:36 -0000 X-Host-Fingerprint: 195.226.6.9 darkcity.gna.ch Linux 2.4/2.6 Received: from ([195.226.6.9:57064] helo=darkcity.gna.ch) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 66/C1-04646-A34CFE24 for ; Tue, 02 Aug 2005 15:06:35 -0400 Received: from localhost (localhost [127.0.0.1]) by darkcity.gna.ch (Postfix) with ESMTP id EA47F1CD2DB; Tue, 2 Aug 2005 21:06:30 +0200 (CEST) Received: from unknown by localhost (amavisd-new, unix socket) id client-XXhyBe5l; Tue, 2 Aug 2005 21:06:29 +0200 (CEST) Received: by darkcity.gna.ch (Postfix, from userid 65534) id 632211CD2DA; Tue, 2 Aug 2005 21:06:29 +0200 (CEST) Received: from [192.168.1.43] (80-219-12-45.dclient.hispeed.ch [80.219.12.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTP id 5B10E1C15CC; Tue, 2 Aug 2005 21:06:26 +0200 (CEST) Message-ID: <42EFC48F.8000901@cschneid.com> Date: Tue, 02 Aug 2005 21:07:59 +0200 User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derick Rethans Cc: PHP Developers Mailing List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on darkcity.gna.ch X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=disabled version=3.0.4 X-Virus-Scanned: by amavisd-new at gna.ch Subject: Re: Property Overloading RFC From: cschneid@cschneid.com (Christian Schneider) Derick Rethans wrote: > class. The magic methods are responsibly for: > - checking if the property actually "exists" This is something I wouldn't encourage as one of the virtues of fully dynamic languages is the "lack" of checking this. Otherwise what happens if e.g. one inherits such a class to extend it? Does it have to know about the get/set methods and the necessary declaration of attributes? And as far as "magic" fields are concerned: IMHO the currently available mechanism of checking the property name against a (possibly e.g. from a DB dynamically created) array in the object is sufficient. So personally I'd not add a language feature as it adds complexity with little (or arguable) gain. My $.02, - Chris