Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64493 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96772 invoked from network); 3 Jan 2013 06:48:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jan 2013 06:48:30 -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.163 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.163 smtp163.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.163] ([67.192.241.163:53146] helo=smtp163.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 77/F3-35624-CB925E05 for ; Thu, 03 Jan 2013 01:48:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 16AB280063; Thu, 3 Jan 2013 01:48:25 -0500 (EST) X-Virus-Scanned: OK Received: by smtp26.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 60D0C80052; Thu, 3 Jan 2013 01:48:23 -0500 (EST) Message-ID: <50E529B6.1050903@sugarcrm.com> Date: Wed, 02 Jan 2013 22:48:22 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Clint Priest CC: PHP Internals References: <50E41BB6.4030901@zerocue.com> <50E4A43E.6030302@zerocue.com> <50E4B232.5000505@mrclay.org> <50E4BDDE.8050509@zerocue.com> <50E4D0BB.7060701@mrclay.org> <50E4FA09.7030001@zerocue.com> In-Reply-To: <50E4FA09.7030001@zerocue.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Within get: $this->Hours can read the underlying property but not write > to it, if it attempts to write, that write would go through the setter. > Within set: $this->Hours = 1 can write to the underlying property but a > read of the property would go through the getter. Are the accesses also applying to called functions/accessors? I.e. consider this: class SuperDate { private $date { get; set(DateTime $x) { $this->date = $x; $this->timestamp = $x->getTimestamp(); } private $timestamp { get; set($t) { $t = (int)$t; $this->timestamp = $t; $this->date = new DateTime("@$t"); } } } What happens to it? Would it get into infinite loop or will just set the value twice? What would be the correct way to write such a code (note the real code of course could be much more complicated and probably involve dozen of properties with complex dependencies between them). Also, if this applies to functions called from getter/setter (which seems to be the case from the code, unless I miss something), consider this: class UserContext { protected $user; public $logger; public $username { get() { $this->logger->log("Getting username"); return $user->name; } set($n) { $this->user = User::get_by_name($n); } } } class Logger { protected $ctx; public function __construct(UserContext $ctx) { $this->ctx = $ctx; $this->logfile = fopen("/tmp/log", "a+"); } public function log($message) { fwrite($this->logfile, "[$this->ctx->username] $message\n"); } } $u = new UserContext(); $u->logger = new Logger($u); $u->username = "johndoe"; echo $u->username; What would happen with this code? Will the log be able to log the actual user name, and if not, how you protect from such thing? $username is a part of public API of UserContext, so whoever is writing Logger has right to use it. On the other hand, whoever is using logger->log in UserContext has absolutely no way to know that Logger is using ctx->username internally, as these components can change completely independently and don't know anything about each other besides public APIs. What I am getting at here is that shadowing seems to create very tricky hidden state that can lead to very bad error situations when using public APIs without knowledge of internal implementation. > Within isset/unset: the same rules apply, a read goes through the getter > and a write goes through the setter. With this code: class Foo { public $bar { get; set; } } How could I make it set to 2 by default and isset() return true when I instantiate the class? Currently, I see no way to assign default values for properties. Is it planned? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227