Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64592 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62877 invoked from network); 6 Jan 2013 01:59:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jan 2013 01:59:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 173.203.6.131 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 173.203.6.131 smtp131.ord.emailsrvr.com Linux 2.6 Received: from [173.203.6.131] ([173.203.6.131:51058] helo=smtp131.ord.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F4/53-62408-D9AD8E05 for ; Sat, 05 Jan 2013 20:59:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id A815D3000A1; Sat, 5 Jan 2013 20:59:54 -0500 (EST) X-Virus-Scanned: OK Received: by smtp21.relay.ord1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id DBEBB300094; Sat, 5 Jan 2013 20:59:53 -0500 (EST) Message-ID: <50E8DA99.1060604@sugarcrm.com> Date: Sat, 05 Jan 2013 17:59:53 -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: Nikita Popov CC: Anthony Ferrara , PHP internals References: <19D80B01-BE88-4119-8A15-B631A96060E5@mrclay.org> <50E8AA4D.5090207@sugarcrm.com> <50E8C2BA.9080309@sugarcrm.com> <50E8CDC8.6080809@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Wait, what are you talking about here? About this particular proposal or > the accessors RFC in general? The fact that unset() can throw a > (catchable) fatal error is just the same without this particular syntax. This is pretty bad by itself. But the fact that everybody would be using this feature in this way - since they would think "I don't need null default, null is always the default and I'd initialize it in the ctor anyway", not realizing that declaring "public DateTime $foo" blocks unset - is even worse. At least with setter you need to explicitly define typehinted setter - and there you have a place to think about it. With "public DateTime $foo" 99% of people would never even remember to think about it - until they'd start getting mysterious fatal errors on unsets. That's why I think it makes it worse. > 1. First of all, there never is a guarantee for everything. All kinds of This is a useless platitude. I've outlines specific scenarios where it fails to do what it seemingly promises to do. > 2. Secondly, the main purpose of typehints is to prevent people setting > incorrect values. If you know that only a "DateTime" instance is valid > and that NULL is not valid, then you should allow only that, only the > DateTime. Allowing NULL absolutely doesn't make sense (as it's not a Allowing NULL is *inevitable*, that's the whole point, since that's what the value is when the object is created, and you can not guarantee this value was initialized. The only thing you can do is to *pretend* it can not be null, even though you know it can be, and ignore the cases where it is null, because you're sure your code is correct. > Your argumentation goes along the lines of "It's possible that this > property could maybe end up being NULL, so it does not make sense to > prevent people from assigning NULL". The second part of that sentence You can easily prevent people from assigning NULL, what you can not do is guarantee the property never returns NULL (at least not with the short syntax, the explicit accessor is a different thing, there you can do it just fine). That's what is wrong with this thing. This shortcut doesn't actually do what people would think it does. It is misleading. > 3. The constructor is typically (or at least that's how it *should be*) > small and doesn't do work, so there isn't much to do wrong. But sure, it "Small" and "work" have wildly different definitions. In real life, constructors frequently call out to other methods when initializing. E.g. somehing like: public function __construct() { $this->log = Logger::getInstance(); $this->db = DBFactory::getInstance(); } or something like that, happens all the time. Now imagine Logger somehow tries to use something that uses $this->db and assumes it's not null - since it can never be null, we declared it not null! > I'd summarize this as follows: The typehint prevents all > incorrectly-typed assignments, but it does not prevent missing > initialization. Your argumentation is that because it can't prevent > missing initialization, we shouldn't bother with preventing incorrect > assignments either. I hope you realize that this makes no sense. It's not my argument. My argument is this syntax makes promise of the value never be null and it is specifically proposed with this sole purpose (and argument is unless it is the promise this syntax has no value at all). And it does not do that. In addition, it breaks unset() which would be completely unexpected by 99% of users. I think in this way it will do more harm than good as it would lead people to write code which behaves worse than if this syntax did not exist. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227