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).