Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74136 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77690 invoked from network); 12 May 2014 20:09:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 May 2014 20:09:10 -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 108.166.43.99 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.99 smtp99.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.99] ([108.166.43.99:40691] helo=smtp99.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7E/5B-10689-46A21735 for ; Mon, 12 May 2014 16:09:09 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 312A61B09E6; Mon, 12 May 2014 16:09:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 993231B09F5; Mon, 12 May 2014 16:09:05 -0400 (EDT) Message-ID: <53712A61.6080604@sugarcrm.com> Date: Mon, 12 May 2014 13:09:05 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Josh Watzman CC: Lazare Inepologlou , Larry Garfield , "internals@lists.php.net" References: <90B71511-4FB4-4916-9AC0-E3DD0D328C37@fb.com> <536D46C5.7040302@sugarcrm.com> <536D50B0.408@sugarcrm.com> <53701BA7.2040809@garfieldtech.com> <53707990.2010507@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > For context/background. Hack has deliberately resisted doing this > since we consider the types to be an integral part of the language. I understand this, and this is a completely valid way of thinking. But I think it's a way, not "the way". > So in our opinion putting things in docblocks just compounds this > problem and can be pretty dangerous if nothing is enforcing them at > runtime. Static analysis and runtime enforcement are different things. Of course, you can do both and they reinforce each other, but I was talking about specifically the point that claimed that "Hack has shown the way". There are other ways to do static analysis (including annotations and type derivation), and as far as I understood from the previous discussion, Hack doesn't enforce types at runtime consistently either, due to integration/BC considerations. So, in my opinion, switching from annotations in docblocks to non-binding annotations in the language doesn't really change the equation with regard to static analysis capabilities. > So this may or may not be a good idea for your use case (I've > honestly kind of lost where this branch of the email thread was > going), but that's why we haven't done it for Hack. Thank you for explaining it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227