Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61708 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62518 invoked from network); 24 Jul 2012 17:42:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jul 2012 17:42:42 -0000 Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.134 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 64.22.89.134 oxmail.registrar-servers.com Linux 2.6 Received: from [64.22.89.134] ([64.22.89.134:43305] helo=oxmail.registrar-servers.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 63/64-42538-19EDE005 for ; Tue, 24 Jul 2012 13:42:42 -0400 Received: from [192.168.0.200] (5ad32874.bb.sky.com [90.211.40.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oxmail.registrar-servers.com (Postfix) with ESMTPSA id 6A9433E8041 for ; Tue, 24 Jul 2012 13:42:38 -0400 (EDT) Message-ID: <500EDE73.6080408@ajf.me> Date: Tue, 24 Jul 2012 18:42:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: internals@lists.php.net References: <500EDBF5.1030805@sugarcrm.com> <500EDC82.1050309@ajf.me> <500EDDA1.1030805@sugarcrm.com> In-Reply-To: <500EDDA1.1030805@sugarcrm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions From: ajf@ajf.me (Andrew Faulds) On 24/07/12 18:38, Stas Malyshev wrote: > 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. What? I'm not suggesting PHP do things because Python does them. I'm just saying that 1) keeping things because they've always been done one way is not a good reason to keep them, and 2) just because Python does the same or a similar thing, does not mean PHP is "turning into Python". -- Andrew Faulds http://ajf.me/