Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63900 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56410 invoked from network); 16 Nov 2012 01:20:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Nov 2012 01:20:59 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.123 smtp123.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.123] ([67.192.241.123:45175] helo=smtp123.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FA/A0-52800-AF495A05 for ; Thu, 15 Nov 2012 20:20:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A8E8C7813A; Thu, 15 Nov 2012 20:20:55 -0500 (EST) X-Virus-Scanned: OK Received: by smtp2.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 0A2EF78132; Thu, 15 Nov 2012 20:20:54 -0500 (EST) Message-ID: <50A594F6.1000407@sugarcrm.com> Date: Thu, 15 Nov 2012 17:20:54 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Clint Priest CC: PHP Developers Mailing List References: <508A67E6.2000405@zerocue.com> <50A39C58.6030501@zerocue.com> <50A3C5AE.7080208@sugarcrm.com> <50A4627F.5000907@zerocue.com> In-Reply-To: <50A4627F.5000907@zerocue.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Fatal error: Call to private method a::__setb() from context ''... > > Or... > > Fatal error: Cannot set private property a::$b. > > Which makes more sense to the most people? Either of these is fine. I'm not talking about that though. You said: "stack traces, reflection, etc would hide the engines implementation details". That means that every part of the engine that deals with stack and reflection should be modified, for no reason other than to hide the scary fact of existence of accessor methods. I think this should not be done - stack traces should show stack as it is, and that's it. Reflection should show the methods as they are, and that's it. No additional complications and special exceptions in order not to hurt the feelings of (imaginary) easily scared and confused users. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227