Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62168 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93949 invoked from network); 15 Aug 2012 08:23:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Aug 2012 08:23:33 -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 67.192.241.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.123 smtp123.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.123] ([67.192.241.123:56207] helo=smtp123.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F1/53-06007-48C5B205 for ; Wed, 15 Aug 2012 04:23:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 07C4F3C134D; Wed, 15 Aug 2012 04:23:30 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 9F2E13C133D; Wed, 15 Aug 2012 04:23:28 -0400 (EDT) Message-ID: <502B5C7F.1070708@sugarcrm.com> Date: Wed, 15 Aug 2012 01:23:27 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Stan Vass CC: "internals@lists.php.net" References: <502A86AA.2030203@sugarcrm.com> <502B57AE.4070801@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > And assignment is a kinda common operation. So I hope you can see what's > wrong with it now. No I do not. Not every imaginable use case should have dedicated language construct for it - sometimes it is OK to type 2 lines of code. Sometimes even 3. This case is well served by existing language syntax, which also allows much more flexibility and control over what happens if the variable does not match. I see no reason to invent language construct the only purpose of which is to save you typing one if clause. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227