Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61706 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60284 invoked from network); 24 Jul 2012 17:38:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jul 2012 17:38:46 -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.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:52087] helo=smtp123.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D1/E3-42538-5ADDE005 for ; Tue, 24 Jul 2012 13:38:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 545CD3C1257; Tue, 24 Jul 2012 13:38:43 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp12.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 557073C128C; Tue, 24 Jul 2012 13:38:42 -0400 (EDT) Message-ID: <500EDDA1.1030805@sugarcrm.com> Date: Tue, 24 Jul 2012 10:38:41 -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: Andrew Faulds CC: Nikita Popov , Laruence , PHP Internals References: <500EDBF5.1030805@sugarcrm.com> <500EDC82.1050309@ajf.me> In-Reply-To: <500EDC82.1050309@ajf.me> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > PHP risks losing some of its uniqueness to fixing things, unfortunately. > But losing bad features and moving forward is good, right? I'm not sure what you are talking about here, but I'm sure I can not accept argument "Python does it this way, so we must do it exactly the same way even if we have to rewrite whole engine and change whole approach of how things done in PHP". If you want exactly what Python does, you always have Python. It's fine to look into what Python does, but how it fits PHP and uses cases of the *PHP* users should always come first, and implementation details of how Python or any other language does things can be a guidance, but never should override this. So if Python does finally in certain way, fine, but it's no no way by itself defines how PHP should do it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227