Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62637 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77855 invoked from network); 1 Sep 2012 23:04:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Sep 2012 23:04:16 -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.147 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.147 smtp147.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.147] ([67.192.241.147:37451] helo=smtp147.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A9/89-17065-E6492405 for ; Sat, 01 Sep 2012 19:04:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp31.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 83470503D6; Sat, 1 Sep 2012 19:04:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp31.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 0991A501BC; Sat, 1 Sep 2012 19:04:10 -0400 (EDT) Message-ID: <5042946A.80204@sugarcrm.com> Date: Sat, 01 Sep 2012 16:04:10 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Pierre Joye CC: PHP Internals References: <5040DC47.8000305@ajf.me> <5040F4D9.80206@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Are exceptions allowed in php core? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! >> SPL is not a part of basic language syntax. There are no SPL keywords >> and no SPL classes used unless you explicitly instantiate those classes. >> So SPL is different. > > End users do not see nor buy the difference between what is Zend/ or > what is ext/spl (or other) and can't be disabled, like SPL. Of course they'd see it. Here it goes again: "There are no SPL keywords and no SPL classes used unless you explicitly instantiate those classes". You can not just write some plain PHP syntax and end up having SPL class. If you use SPL class, you must do "new SplSomeClass" or something similar. It has nothing to do with disabling. > I really think we should consider exceptions, step by step, for the > language itself, when it makes sense. And the generators RFC is one We should consider them, but we should not do it in ad-hoc manner. It doesn't work ad hoc - this is exactly what keeps giving PHP users grief and PHP as a project reputation of environment that makes no sense - introducing stuff in random places without regard to how other parts of the language work. Why this piece has exceptions and that doesn't? Oh, that's because one guy implemented that part, another guy implemented this, they didn't want to get to agreement on this, so they just did completely different things in two places. And how the user is expected to work with both? Well, not anybody's problem, each guy got his piece committed, written in his favorite style, matching his unique use case, and couldn't care less about anything else. This is not how language environment should be properly designed. When (and if) we have a model of using exceptions in core, then we can introduce them in core, but introducing them piecemeal in random places just because people fell like it, without any plan or design is just not right. We have to stop doing it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227