Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64582 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44546 invoked from network); 6 Jan 2013 00:18:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jan 2013 00:18:09 -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.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.143 smtp143.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.143] ([67.192.241.143:52825] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B5/EF-62408-0C2C8E05 for ; Sat, 05 Jan 2013 19:18:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 96DF13A015B; Sat, 5 Jan 2013 19:18:05 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 0AD233A0251; Sat, 5 Jan 2013 19:18:02 -0500 (EST) Message-ID: <50E8C2BA.9080309@sugarcrm.com> Date: Sat, 05 Jan 2013 16:18:02 -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: Anthony Ferrara CC: Nikita Popov , PHP internals References: <19D80B01-BE88-4119-8A15-B631A96060E5@mrclay.org> <50E8AA4D.5090207@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! > "Too much magic"? It's completely consistent with how method parameters > work now. In fact, I'd argue that introducing a new syntax for this > would be inconsistent with the current paradigm. But this in for methods, and you are putting it into entirely different place - property initializer. That's what I call magic - somehow property initializer magically becomes method parameter's default value. > This becomes especially true if initializers are added, where the > property would be initialized to a non-null value. Hence adding the > ability for it to *never* actually *be* null in the first place... I think property initializers won't work well, especially combined with this syntax. What should public DateTime $foo = 42; produce? Essentially it looks like the only initializer useful here would be NULL. In this case, why not just make it simple and always allow NULL there and get rid of the confusing syntax? You'd have to allow NULL anyway since otherwise you'd be unable to implement unset() and won't have any useful isset(). In fact, initial value of any object property will always be NULL, so not allowing NULL is pointless as there's always NULL there when you start. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227