Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63669 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48403 invoked from network); 27 Oct 2012 18:05:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Oct 2012 18:05:39 -0000 Authentication-Results: pb1.pair.com header.from=cpriest@zerocue.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cpriest@zerocue.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender) X-PHP-List-Original-Sender: cpriest@zerocue.com X-Host-Fingerprint: 67.200.53.250 mail.zerocue.com Received: from [67.200.53.250] ([67.200.53.250:51398] helo=mail.zerocue.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/9C-51104-E622C805 for ; Sat, 27 Oct 2012 14:05:39 -0400 Received: from [172.17.0.122] (unknown [72.179.52.187]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.zerocue.com (Postfix) with ESMTPSA id 43512120165; Sat, 27 Oct 2012 18:05:32 +0000 (UTC) Message-ID: <508C2267.2040205@zerocue.com> Date: Sat, 27 Oct 2012 13:05:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Patrick Schaaf CC: internals , Stas Malyshev References: <508A67E6.2000405@zerocue.com> <508AF476.9040804@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability From: cpriest@zerocue.com (Clint Priest) That's why I think they shouldn't even be visible to users, they aren't relevant to them and in fact it could mis-lead them into thinking that they could simply define __getHours() and expect $foo->Hours to call it, which it wouldn't. To me, the bottom line is, the fact that there are methods defined by accessors is an engine detail and not something that should be exposed to the user. As for the __set_state() issue, I can see the need to change the pattern of method naming, I'd be amenable to anything. Everyone okay with __get_prop_hours() naming convention then? On Saturday, October 27, 2012 3:01:39 AM, Patrick Schaaf wrote: >>> - i.e. name them __prop_get_xxx, __prop_set_xxx, and so on. >> >> I think it'd more natural to make it __set__PROPNAME. Though __set_state >> is a static method, so maybe we can live with it - except that you won't >> be able to declare property named $_state. > > Needing an "except" is inelegant, if it can be avoided up front. > > Also, having __prop_get_XXX etc. is a bit more descriptive to somebody > later "wondering" what these methods are - prop alludes to properties, > which is what the methods are about. I can already see the stack overflow > subject, "what are these __prop methods in new PHP" :) > > best regards > Patrick > -- -Clint