Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50706 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4147 invoked from network); 29 Nov 2010 19:57:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Nov 2010 19:57:03 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 ns.km36107.keymachine.de Solaris 10 (beta) Received: from [217.114.211.66] ([217.114.211.66:56757] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5E/A5-09015-D8504FC4 for ; Mon, 29 Nov 2010 14:57:02 -0500 Received: from [192.168.1.29] (ppp-93-104-117-198.dynamic.mnet-online.de [93.104.117.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id BA6804B365; Mon, 29 Nov 2010 20:56:58 +0100 (CET) To: larry@garfieldtech.com Cc: internals@lists.php.net In-Reply-To: <4CF40195.7060101@garfieldtech.com> References: <4CF3B903.6000204@gmail.com> <4CF3EE8A.4000405@garfieldtech.com> <1291056116.6129.1.camel@guybrush> <4CF40195.7060101@garfieldtech.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 29 Nov 2010 20:56:57 +0100 Message-ID: <1291060617.6129.13.camel@guybrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Mon, 2010-11-29 at 13:40 -0600, larry@garfieldtech.com wrote: > I still want to keep the performance implications in mind, as this > sounds like something that we'd want to use a lot but could also cost a > lot more than it seems at first glance if we're not careful. By making properties in memory a little bigger one might write the accessors in the same table as the actual properties one might possibly reduce the CPU requirement abit. While one has to touch most places dealing with properties internally (while that's probably needed anyways). But well, unless there is an implementation all performance ideas are guesses ... educated guesses at best. johannes