Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71645 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11550 invoked from network); 27 Jan 2014 17:28:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jan 2014 17:28:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=rewilliams@thesba.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rewilliams@thesba.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain thesba.com designates 208.106.205.210 as permitted sender) X-PHP-List-Original-Sender: rewilliams@thesba.com X-Host-Fingerprint: 208.106.205.210 ntsexchedgea1.newtekemail.com Received: from [208.106.205.210] ([208.106.205.210:16518] helo=ntsexchedgea1.newtekemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1A/E1-01140-25796E25 for ; Mon, 27 Jan 2014 12:28:52 -0500 Received: from NTSEXCHHUBA1.NTS.PHX1 (208.106.205.208) by NTSEXCHEDGEA1.newtekemail.com (208.106.205.210) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 27 Jan 2014 10:28:46 -0700 Received: from NTSEXCHA1CMB2.NTS.PHX1 ([fe80::3913:915c:3f89:aad]) by NTSEXCHHUBA1.NTS.PHX1 ([2002:d06a:cdd0::d06a:cdd0]) with mapi; Mon, 27 Jan 2014 10:28:47 -0700 To: PHP internals Date: Mon, 27 Jan 2014 10:28:46 -0700 Thread-Topic: [PHP-DEV] Ruminations on PHP 5++ Thread-Index: Ac8bhTvwHBYJFZT8QVSdVyRy7fqLTw== Message-ID: References: <52E29253.2000801@lsces.co.uk> <52E2924B.6080002@ajf.me> <52E299D4.6040102@garfieldtech.com> <52E2C98C.6010005@lerdorf.com> <52E2D8D2.80106@lerdorf.com> <52E64D10.5020404@hristov.com> <52E65975.5040508@lsces.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PHP-DEV] Ruminations on PHP 5++ From: rewilliams@thesba.com (Robert Williams) I=92d like to offer a few thoughts as another user-lander: - I couldn=92t care less about PDO as I never use it. Most of my work is on= corporate applications, and frankly, I care much more about the performanc= e of my applications *now*, every day, than I do about the ability to later= switch to another database - a path that we may or may not ever try to tak= e. When you care about performance, and your database is non-trivial, cross= -database-compatibility is a pipe dream because you need to optimize your q= ueries (and certain schema choices) to the database engine. Even just using= MySQL, for example, optimizing for MyISAM versus InnoDB are two very diffe= rent things. So if we did switch databases, we'd be reworking queries, anyw= ay. That=92s just part of life as a web developer. For these same reasons, = we don=92t use any of the trendy ORM frameworks, since their whole point of= existence is take away the =93drudgery=94 of writing queries. The database= layer is the single biggest bottleneck in most applications, and I=92m not= about to leave responsibility for it to generic framework code. Given all = this, what I=92d like to see is evolution of the mysqli API: improved perfo= rmance, improved documentation, etc. - Perhaps as a bit of a continuance of the previous point, I don=92t see a = lot of value, in general, in adding built-in APIs to do things like logging= or auto-loading. If they=92re lightweight, I=92d probably use some of them= if they were available, but I don=92t really miss them that much now. Such= things, while present in most real-world applications, are also such a sma= ll part (code-wise and effort-wise) of those applications that even writing= them from scratch every time makes for a pretty small waste of time - a fe= w hours in a sea of thousands of hours. And, I suspect that few write them = completely from scratch every time, as it=92s quite easy to evolve one=92s = own libraries for these things. Thus, I=92m not against these things per-se= , but I would prefer the dev time go to more impactful changes. - I know this has been discussed again recently, but I=92d love to see erro= r handling reworked. A couple of wacky examples: Why do I have to use the @= operator on fopen() calls to keep PHP from spitting out warnings, when the= return value tells you if it was successful? PHP should never, ever spit o= ut warnings or notices in cases where error-handling code will catch the pr= oblem. And, why, to handle errors myself when instantiating a SimpleXMLElem= ent object, do I need to toggle user error handling, then call a procedural= function to get a list of errors? Why not simply throw an exception? After= all, SimpleXMLElement is an OO API wrapper designed to simplify libxml use= , but some of that ease is defeated when I need to wrap the wrapper just fo= r error handling. - On another topic that=92s been the source of debate over the years, I=92d= love to see the project move to C++. That doesn=92t mean all existing code= needs to be rewritten just for the sake of conversion, but it=92d great if= new code could be done in C++. I=92d like to contribute, but my C skills, = which, honestly, were never razor-sharp to begin with, are now suffering fr= om a couple of decades of disuse. Throw in the frequently discussed lack of= documentation, the state of the code (patchy), and the inherent complexity= of a project like PHP, and it=92s pretty tough for someone like me to get = going in a meaningful way and with a dedication of time that I can actually= afford as a working family man. - And yes, I=92d love to have a coherent cross-API design. I understand the= glue history of the language, but as a user-land developer, I don=92t real= ly care. That one time that I need to use the mysql library from C, well, I= =92ll hit the docs; I would expect no less. But I don't expect to have matc= hing APIs in my high-level language (PHP). Besides, with all the difference= s that are bound to be in there beyond function name and argument order (sa= y, whether an arg is passed as an int or char, or whether it=92s passed by = ref), I really don=92t think that the little bit of familiarity assistance = gained at the lower level is worth the loss of consistency at the higher le= vel. After all, where do most PHP programmers spend most of their time? Aga= in, it=92s about putting limited dev time to concerns that are more impactf= ul, and a consistent API is easily more impactful than vague API familiarit= y for a tiny slice of PHP developers. Now, a lot of ideas have been thrown = about around on how to achieve this, and at this early juncture, I think I = could live with most of them if it means moving toward a designed language = rather than an evolved one. - Finally, improved performance and memory management are absolutely always= good things, as are things like simplified configuration and improved secu= rity features. -- Robert E. Williams, Jr. Senior Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information = that is confidential. It constitutes non-public information intended to be = conveyed only to the designated recipient(s). If the reader or recipient of= this communication is not the intended recipient, an employee or agent of = the intended recipient who is responsible for delivering it to the intended= recipient, or if you believe that you have received this communication in = error, please notify the sender immediately by return e-mail and promptly d= elete this e-mail, including attachments without reading or saving them in = any manner. The unauthorized use, dissemination, distribution, or reproduct= ion of this e-mail, including attachments, is prohibited and may be unlawfu= l. If you have received this email in error, please notify us immediately b= y e-mail or telephone and delete the e-mail and the attachments (if any).