Re: Ruminations on PHP 5++

I’d like to offer a few thoughts as another user-lander: - I couldn’t 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 performance 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 take. When you care about performance, and your database is non-trivial, cross-database-compatibility is a pipe dream because you need to optimize your queries (and certain schema choices) to the database engine. Even just using MySQL, for example, optimizing for MyISAM versus InnoDB are two very different things. So if we did switch databases, we'd be reworking queries, anyway. That’s just part of life as a web developer. For these same reasons, we don’t use any of the trendy ORM frameworks, since their whole point of existence is take away the “drudgery” of writing queries. The database layer is the single biggest bottleneck in most applications, and I’m not about to leave responsibility for it to generic framework code. Given all this, what I’d like to see is evolution of the mysqli API: improved performance, improved documentation, etc. - Perhaps as a bit of a continuance of the previous point, I don’t see a lot of value, in general, in adding built-in APIs to do things like logging or auto-loading. If they’re lightweight, I’d probably use some of them if they were available, but I don’t really miss them that much now. Such things, while present in most real-world applications, are also such a small 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 few hours in a sea of thousands of hours. And, I suspect that few write them completely from scratch every time, as it’s quite easy to evolve one’s own libraries for these things. Thus, I’m 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’d love to see error 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 out warnings or notices in cases where error-handling code will catch the problem. And, why, to handle errors myself when instantiating a SimpleXMLElement 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 for error handling. - On another topic that’s been the source of debate over the years, I’d love to see the project move to C++. That doesn’t mean all existing code needs to be rewritten just for the sake of conversion, but it’d great if new code could be done in C++. I’d like to contribute, but my C skills, which, honestly, were never razor-sharp to begin with, are now suffering from 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’s 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’d love to have a coherent cross-API design. I understand the glue history of the language, but as a user-land developer, I don’t really care. That one time that I need to use the mysql library from C, well, I’ll hit the docs; I would expect no less. But I don't expect to have matching APIs in my high-level language (PHP). Besides, with all the differences that are bound to be in there beyond function name and argument order (say, whether an arg is passed as an int or char, or whether it’s passed by ref), I really don’t think that the little bit of familiarity assistance gained at the lower level is worth the loss of consistency at the higher level. After all, where do most PHP programmers spend most of their time? Again, it’s about putting limited dev time to concerns that are more impactful, and a consistent API is easily more impactful than vague API familiarity 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 security 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 delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).