When trying to make things “user friendly”, a lot of good ideas seem to get subjected to Chinese Whispers or Cargo Cult treatment, and end up either counter-productive, or at least unnecessarily annoying. One such idea is formatting dates and times as easy-to-read relative terms, like “5 minutes ago”, or “yesterday”. It makes everything look less dull and technical, and someone probably did some studies once showing that it’s easier to read in some particular context. On the other hand, it means actively hiding information from the user, and is implemented badly more often than well, leading to sentences that are misleading, useless, or just plain nonsense.
If you are ever implementing such a feature for an application or as a library, below are some tips which you really should consider. If you have written, or come across, a library that does it right, please let me know in the comments, so I can shout at anyone who uses something braindead instead.
For most of its life, PHP has been a “weakly” typed language: values can freely shift from one state to another, and mould themselves to what an operation requires; or, in the case of objects, largely duck-typed: you don’t need a formal contract to call a method. There is, however, a trend in the language to adopt stronger typing constraints, first in function parameters, and now elsewhere in the language. As with so much in PHP, this is being done piecemeal, and without a clear road map. This is partly deliberate: a gentle introduction of optional features is less disruptive; but it is dangerous: compromises made now will shape the language for years to come.
I think it is time to grasp the nettle and say that there is a definite policy of introducing a new typing model to PHP, and a roadmap of what that means for the language. The implementation may still be incremental, but each change will be a step in a consistent direction. This post is my musings on what such a model might look like.
There are a lot of URLs out there on the Web; and a pretty big number of those URLs are either alternative names for something, or old locations that have been superseded. So “redirects” from one URL to another are a common feature of the web, and have been for many years. But recently, the way these redirects behave has been changing, because performance-conscious browser developers have started caching redirects, rather than re-requesting them from the server every time.
In theory, this makes perfect sense, but in practice, it causes web developers like me a lot of pain, because nothing “permanent” is actually that permanent. I’m not saying no browser should ever cache a redirect, but I do have a few suggestions of ways they could be a little more helpful about it.
A recent blog post from my old friend Phil ((well, vaguely recent: I really should get with this whole RSS thing!)) discussed some of the gotchas of parameter passing in object-oriented languages – or I suppose specifically in partially OO languages, since the problem in this case was a combination of objects and structs in C#.
It seems to me there is a genuine problem here, beyond programmer fallibility – the old distinction between “pass by value” and “pass by reference” is no longer a useful distinction in such languages, and someone needs to design something better.