What if…

Menu

Tag Archives: PHP

Post navigation

There is some renewed discussion about introducing static typing in PHP. I just read one very interesting post: The Safyness of Static Typing which I suggest everybody that is interested in this topic should read (and the links there). You may agree or disagree, but it is worth reading and even if you disagree it is worth ensuring you know the answers to the questions raised there, otherwise your disagreement lacks substance. I must admit I liked that post because it agreed with my feelings (not substantiated prior to that by any experimental data besides general experience I’ve acquired in the field) that type safety is not as close to silver bullet as some put it.

Within the context of PHP, I’m not sure if more strict typing (coercive typing is something in between and would require a bit different treatment) would be beneficial. I can see where it could be useful – i.e., for making JIT it probably would be very nice. On the other hand, Javascript has excellent JIT engines, as I have heard, without any additions of strict typing, so it’s not absolutely necessary. With PHP code living in runtime and static analysis tools not being routine part of mainstream development, at least as far as I have seen, I’m not sure addition of strict typing would help in any substantial way. Facebook guys, obviously, disagree – I wonder if they have some data to back it up, i.e. how that worked in practice and especially how “hybrid” model – i.e. having typed and untyped code coexist (that as I understand is what is happening, may be I am wrong here) works out and if it indeed provides better safety and reduced development time?

P.S. oh, and if you want a surefire way to annoy me, please call strict typing “type hinting”. I’m sure in the history of PHP there were examples of worse terminology (“safe mode” comes to mind as one) but that does not excuse this most unfortunate decision to name strictly typed arguments “hinting”.

Almost 8 years ago, I wrote “What is PHP anyway?“. This blog is supposed to be about some long-term dreams, and in this case it was the dream come true – Sara Golemon and the excellent Facebook team made a draft PHP spec and with some paint and polish it can become a real spec pretty soon. Not sure if it can be ready by the 8th anniversary of that post, but it probably will be out by the 9th :)

Talking to people, I recently discovered not everybody knows this thing exists. So here it goes – it exists right here. It is still a draft. If you see something wrong, submit a pull request. If you feel you can contribute more by working on it or refining some points, “standards” mailing list was re-purposed to be the working group list.

Having taken a look in the past, now it’s time to look into the future, namely 5.6 (PHP 7 is the future future, we’ll get there eventually). So I’d like to make some predictions of what would work well and not so well and then see if it would make sense in two years or turn out completely wrong.

High impact

I expect those things to be really helpful for people going to PHP 5.6:

Constant expressions – the fact that you could not define const FOO = BAR + 1; was annoying for some for a long time. Now that this is allowed I expect people to start using it with gusto.

Variadics – while one can argue variadics are not strictly necessary, as PHP can already accept variable number of args for every function, if you’re going to 5.6 the added value would be enough so you’d probably end up using them instead of func_get_args and friends.

Operator overloading for extensions – the fact that you can sum GMP numbers with + is great, and I think more extensions like this would show up. E.g., for business apps dealing with money ability to work with fractions without precision loss is a must, and right now one has to invent elaborate wrappers to handle it. Having an extension for this would be very nice. Finding a way to transition from integer to GMP when number becomes too big would be a great thing too. Still not convinced having it in userspace is a great idea, what C++ did to it is kind of scary.

phpdbg – not having gdb for PHP was for a long time one of the major annoyances. I expect to use it a lot.

Low impact

Function and constant importing – this was asked for a long time, but I still have hard time believing a lot of people would do it, since people who need imports usually are doing it in OO way anyway.

Hurdles

OpenSSL becoming strict with regard to peer verification by default may be a problem, especially for intranet apps running on self-signed certs. While this problem is easily fixable and the argument can be made that it should have been like this from the start – too many migrations go on very different paths depending on if it requires changing code/configs or not.

Adoption – again, with 5.5 adoption being still in single digits, I foresee a very slow adoption for 5.6. I don’t know a cure for “good enough” problem and I can understand people that do not want to move from something that already works, but look at the features! Look at the performance! I really hope people would move forward on this quicker.

While 5.4 will always have a special place in my heart, I hope people now staying on 5.2 and 5.3 would jump directly to 5.6 or at least 5.5. The BC delta in 5.5 and 5.6 is much smaller – I think 5.3->5.4 was the highest hurdle recently, and 5.4 to 5.5 or 5.6 should go much smoother.

Anything you like in PHP 5.6 and I forgot to mention? Anything that you foresee may be a problem for migration? Please add in comments.

With 5.6.0 having been released and 5.4 branch nearing its well-earned retirement in security-fixes-only status I decided to try and revive this blog. As the last post before the long hiatus was about the release of the 5.4, I think it makes sense to look back and see how 5.4 has been doing so far.

Great

Release process. Combined with RFCs and git. It’s hard to believe we used not to have it. RFC process is working great, git makes all the processes tick and we have scheduled releases, working CI setup and much better predictability and management of releases overall. It’s no big deal unless you remember how it was before.

Built-in webserver. It really helps when you can just set up something browseable (is this a word? now it is) with PHP alone, without bothering with Apache setup and other moving parts. This is again a case of something that you don’t realize how much you missed it until you start using it.

$this support in closures. Having to write 5.3-compatible code for the last couple of years, I can’t emphasize enough how sorely it was missing in 5.3. I really regret the fact we could not get it into 5.3.

Syntax sugar like [] and <?= working everywhere. It’s a small thing but it adds up. I usually do not give much weight to saving couple of keystrokes and so on, but these to me really improve coder’s quality of life.

Removal of old “features” (since they ended up in the dump, is it right to call them features anymore?). Nobody is missing the safe mode or magic quotes or register_globals. Good riddance. Wish we parted ways sooner.

Meh

Traits. I must say I haven’t seen big adoption of the traits feature. Yes, of course people use it, there are tutorials, there are articles, etc. But at the same time compared to how much namespaces were needed or how much closures proved to be a great help, traits adoption, IMHO, remains lukewarm at best. To me, it has not lived yet up to its promise. Maybe I’m missing something, tell me if you have great examples there.

Adoption. This is a problem for new PHP versions and for developers of distributable PHP software – PHP versions are becoming “good enough” and people are reluctant to move forward, which also delays adoption of new features by library & packaged software writers. Look at the numbers: almost 3/4 of the PHP developers are using EOLed versions! 5.4 adoption is low at 22% and 5.5 adoption is abysmal. I hope that more streamlined release cycles and heightened attention to BC matters would bend this tendency. But so far it is not encouraging. WordPress numbers look even worse.

Don’t know

callable type. How wide is the usage? How useful it is in practice? Is it being used in major projects? I really don’t know.

Performance. It feels weird to put an obviously great improvement in this category. I would expect performance be a major driver for people to move forward, but the numbers suggest otherwise. As much as I love the performance improvements (a lot!), I really have no idea on how much it influenced the community and made them go to 5.4 (or beyond). Are there any surveys, links, studies, etc. in this regard? I see a lot of talk about performance but how many people also walk the walk? Are the numbers quoted above misleading?

mysqlnd. 5.4 is the first version where mysqlnd is the default mode of doing mysql. It has better performance, great features and I’ve been using it for years without a problem. But how widely it is adopted – do people still prefer the old way or love the new one? Do they use the plugin API widely?

Anything else?

Did I forget to mention something that really made your life better in 5.4? Did I conceal some flop that you wish we didn’t do? Please tell.

Since May 2011 we have worked on releasing PHP 5.4, and now it happened. Thanks everybody who helped with it!

PHP 5.4 has some new and exciting features – for some of them, like traits, I have no idea right now how they will work out and what people would do with them. It’d be very interesting to see.
For some of them, I feel they are basic common sense and long overdue in PHP (of course, not everybody may share my opinion ;) – like [‘short’,’array’,’syntax’] or detaching <?= from INI settings. Some were just missing features that we didn’t catch up with before – more fluent syntax, linking objects to closures, etc.
Some things in PHP, as we have come to realize, were clearly mistakes – like register_globals, some were driven by real needs but proved to do more harm than good at the end – like magic quotes and “safe” mode – so we had to lay them to rest.

One of the best things that happened in 5.4 though is not immediately apparent. The engine behind 5.4 is significantly faster and consumes less memory than before. How much faster and how much less? Depends on your application, of course, but from some benchmarks 10-20% speed improvement and 20-30% memory improvement can be expected. Do your own benchmarks and blog about the results! Also would be a good time to ensure your application runs fine on 5.4 – since 5.4 is now the stable version and you have to start using it! :)

Another great things that happened – and is continuing to happen – is that we are finally moving towards more streamlined release process, towards having more regular releases (expect 5.4.1 release cycle to start in late March-early April and 5.4.1 be out in about a month after that) and more organized feature/change proposal process. There’s a wiki where people can post their RFC proposals, we have a voting process and while we may be still working out some fine details of the procedure, I feel we definitely have improved in this regard. It is time to get some organization into the process – we don’t need to create a bureaucracy, but some process is definitely needed and we’re establishing it.

Yet another thing that is happening – PHP project is slowly but surely moving from SVN to Git. This will be a great improvement. Having used Git for the last couple of years, I can clearly see that it can make many things we’re doing in PHP everyday so much easier. Can’t wait for it :) Also makes easy for people to do pull requests and for core devs to merge them, among other things – should make bug resolutions, etc. work faster.

And after catching our breaths a bit and relaxing soon there will be time to think what we do in 5.5 – remember the thing about more regular releases? :) I’ll try to post some thoughts about what I’d want in 5.5 soon.

I am using Zend Studio for my everyday PHP work, and I like it. I know many others do too, or use PDT. It has one very cool – though not widely known – feature that allows you you to add unknown extensions to code completion. I.e., if you have some extension, create stub file with PHPDOC descriptions – i.e. something like this:

for each extension function, Studio will know to pick it up. You can put this file into Studio’s prototypes directory – easiest way to find it is just write something like chdir() anywhere, select the name and press F3, the directory of the file that you’ll get is the one you need.

However, the problem is how to create this file. E.g., I’m doing some work with MongoDB lately, and PHP has great Mongo extension – which Studio doesn’t know yet. So how do I create those stubs? Obviously, I am too lazy to manually write them. I went to look for a tool that would allow me to make one – and found none. At least not in 15 minutes I spent looking, so I decided to write my own.

What came out is the Reflector. It uses PHP reflection and PHP’s manual XML sources in order to generate stub file (see example mongo.php on git to check what comes out). Right now it’s not very smart and handles only classes/methods, not functions (probably will fix that soon), but maybe it will be useful to somebody.

Or maybe somebody points me to a tool that does that even better in comments :)

Update: Roy Ganor (who is leading the Zend Studio project) in comments pointed me to the source of the Studio generator script. It will generate stubs for all extensions you have, as I can see. Try it out. Thanks, Roy!

I think it is a great book for somebody who is somewhat acquainted with Zend Framework and wants to get really good at working with it. It covers a lot of ground, so if you never worked with ZF before you might be a bit overwhelmed by the amount of stuff going on (then again, maybe I am underestimating you :) ), so you may want either skip some detail to return to it later when the need arises or have a run through a very basic tutorial for getting to know how the framework works before. The book itself has the basic startup section but I feel for a complete newbie it still might be a bit tough to keep up with the amount of the material in the book. That of course will come handy later when you got the basics figured out.

I personally am a big fan of learning by example and I think one line of code is often worth a hundred words, so I was really pleased that this book is based on building a complete application and comes with full application code to accompany it. The application is a storefront with an admin interface, so it covers most of the common tasks in a typical PHP application.
While it means that on the road there were certain decisions to be taken, and certain ways of doing things will be chosen over certain others, the author clearly identifies the decision points and explains the reasons – i.e. why certain things go to a model and not controller, why this extension point and not that one is used, etc. ZF has a very rich set of features, so there’s no single “right way” to do all things – but the book certainly shows you one of the ways to reach the complete and nicely structured application.

I actually took a bit of an experiment – as I was at the time building some ZF-based application, I decided to use the book as a first reference for any question that I needed with the app. I am pleased to report that the book indeed proved very helpful and I was able to find most of the advanced topics – like the use of ACLs, interactions between forms, views and decorators, modifying the behavior of the standard ZF classes, etc. – answered in the book and demonstrated in the code. The author successfully avoided the temptation to quote the manual extensively and instead picks up where the manual leaves off – i.e. how does one use stuff that the manual describes in practice.

The book also covers – albeit somewhat lightly – the topic that is neglected by so many other ZF books – namely testing. It shows how to setup the test environment and how to execute some basic application tests. Ideally, I would like the topic of tests to be much more prominent and featured as something parallel to development and not something you do after (though I know that’s how it rally happens many times ;) ) – but I know there’s only so much you can put into one book :)

Summarily, I think it is a good book to have if you do or about to do serious ZF development.