Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67841 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36144 invoked from network); 25 Jun 2013 23:16:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jun 2013 23:16:25 -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 108.166.43.75 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.75 smtp75.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.75] ([108.166.43.75:58346] helo=smtp75.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 99/65-11452-8C42AC15 for ; Tue, 25 Jun 2013 19:16:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D2CCB1E80BF; Tue, 25 Jun 2013 19:16:21 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 8D7D41E80B8; Tue, 25 Jun 2013 19:16:21 -0400 (EDT) Message-ID: <51CA24C5.9090505@sugarcrm.com> Date: Tue, 25 Jun 2013 16:16:21 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Anthony Ferrara CC: "internals@lists.php.net" References: <51C9FA9C.8050403@sugarcrm.com> <51CA1C93.6080500@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RFC: Protocol Type Hinting From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > So nobody should ever use libraries, because they can't be sure of that > code... So... Libraries have classes and interfaces for exactly this reason - so you can be reasonably sure what's in them or at least have easy way to check it. > It's checking that fatal method-not-defined erros won't be thrown... But instead a fatal "protocol does not match" error will be thrown. The difference? > It gives the ability for a method to be defensive by preventing E_FATAL > errors. That's not adding something significant? I fail to see the difference between one error and another error. The whole "catchable" thing is very artificial difference and as far as I'm concerned, if that's the problem, just make method-not-defined "catchable", whatever that might mean - there's no difference on the substance that I can see. > I agree the use-cases are slightly weak. This is a draft RFC. It's > supposed to help identify the areas where we can improve it. Help > identify use-cases. Help dig it out. My personal opinion regarding design always was that use cases come first. If I don't have a use case, there's nothing to design. So I'd like to see the convincing use case first. Then, once it's convincing, we can talk about implementation details - so yes, you can discard all the performance, etc. talk - it's not important right now, the most important thing is the use cases. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227