Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:18418 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35863 invoked by uid 1010); 25 Aug 2005 12:49:17 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 35844 invoked from network); 25 Aug 2005 12:49:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Aug 2005 12:49:17 -0000 X-Host-Fingerprint: 192.38.9.232 gw2.emini.dk Linux 2.4/2.6 Received: from ([192.38.9.232:3877] helo=gw2.emini.dk) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 76/5B-28235-B4EBD034 for ; Thu, 25 Aug 2005 08:49:15 -0400 Received: from [10.0.0.18] (palestine.intra.emini.dk [10.0.0.18]) by gw2.emini.dk (Postfix) with ESMTP id E83687815C; Thu, 25 Aug 2005 14:49:10 +0200 (CEST) Message-ID: <430DBE46.4090406@emini.dk> Date: Thu, 25 Aug 2005 14:49:10 +0200 Organization: Emini A/S User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schneider Cc: Derick Rethans , PHP Developers Mailing List References: <430DBD80.6090804@cschneid.com> In-Reply-To: <430DBD80.6090804@cschneid.com> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=157D0FA8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Property Overloading RFC From: edink@emini.dk (Edin Kadribasic) Christian Schneider wrote: > Derick Rethans wrote: > >> I updated the proposal: >> http://files.derickrethans.nl/property_overloading.html >> >> If nobody as any better idea on how to solve it I'd like to start >> implementing it. > > > I seem to remember that we had some voices here stating that the current > mechanisms are sufficient. Adding new keywords and/or new magic methods > is something which should have a very high threshold as it complicates > the language. > > To me the proposal looks like a worst of both worlds kind of compromise: > Add new keywords and magic methods coupled with (ab)using the (in this > context somewhat inelegant) __get/__set mechanism. > > So I'd rather not see this implemented to be honest. I could not agree more! Edin