I've used PHP a lot, work at a name-brand startup that uses a fair bit of PHP in the stack, and have an OSS PHP project I'm proud of (https://github.com/shaneharter/PHP-Daemon). That is to say, I'm not a PHP hater. I see many flaws in the language, many many actually, but I'm not a hater.

But I really disagree with some of this.

First, why call variable references "pointers"? You're just breeding ignorance there. Understanding pointers is a valuable skill for a software engineer, even if they'll never use the skill directly in their day job as a PHP developer.

Second, you're introducing concepts that are a little sleazy like variable variables without any commentary on downsides or best practices. There is effectively nothing you can do with a variable variable that you cannot do with an associative array.

And fine, if you don't want to editorialize, if you want to just teach facts of the language without adding opinion, why invent the term "pointers" that, as far as I've ever read, is not used in any official PHP documentation.

Agreed on some points. A mention of the serious trouble you can get in with variable variables is in order. I would never feel comfortable using user input to dictate a variable reference.

I think it would have been worth pointing out the slightly more readable syntax for variable variables (and other metaprogramming features within PHP):

    ${$var};
    ${$name.'Controller'}->function();
    $something->{$functionName}();

With all the appropriate warnings, of course. For a start, don't find excuses to implement this style of code. You almost certainly don't need it for a basic website.

For TimeClass one should not assume 86400 seconds in a day, and use DateTime::diff() instead. PHP The Right Way is better on this: http://www.phptherightway.com/#date_and_time

With the autoloader, there is no need to do include_once(), simple include() is enough. The file will be loaded only once for every class.

Nearly any time you think "I need to have variable variable names", you should probably be using an array (dictionary, hash, whatever your language gives you). They're no more difficult to use & far harder to make horrible mistakes with.

I'm not one to complain about the distribution of training information, but isn't this a little... simplistic for HN? This seems more the typical /r/PHP content.

I mean, is there anyone here who doesn't know what the ternary operator is?

I'd be willing to be that 90% of people here don't know what the PHP ternary operator does.

(It's left associative, unlike literally every other language that has a ternary operator.)

Maybe it's a counter-reaction to the oh-so-common PHP bashing. "Hey, an article that discusses PHP in a neutral tone, lets upvote this"

This is an excellent example of how _not_ to write code.

Custom autoloading scheme instead of PSR-0? Classname.inc.php, seriously? Moving on, dynamic variables are a terrible unfeature that should be avoided. References usually cause more harm than good and should be avoided as well. And finally, a class which is named with a redundant "Class" suffix, containing only static members, aka class-oriented programming.

Loved it! From basics to really useful example. Is there any way to see the schedule of posts?

The TimeClass:relative() function is a bit nasty, how many times do you need to calculate date('d/m/Y', $time) ?!.

[edit] Or, time() for that matter, in fact this could be a subtle bug, as the return value of time() may vary throughout the function (unlikely, I know!)

Subtle and hard to trace bugs, yes. Can also happen if time() is used several times in a request, but in different functions. I've taken to preferring $_SERVER['REQUEST_TIME'] in most cases.

If you're spending a few seconds rendering HTML, you probably have other big problems to solve above optimizing around time().

That's the thing. You don't have to. Two subsequent SQL INSERTs may occur only microseconds apart, but the result may still differ by a second, causing a problem with datetime. And it's horribly naieve to think every request always completes in a few milliseconds. There are plenty of good reasons a request may take a longer time. From overloaded servers to network congestion to long running cronjobs or other processes.

Depending on the situation you would want database inserts to reflect the passage of time, and not always stick to a 'start of request/job' time. I can see the desire of the parent to want to have all the HTML generated with the same understanding of time, but as a general practice I still think its a bad one to fix time.

`spl_autoload_register()` is awesome. This is how we implement it:

    spl_autoload_register(function ($class_name) {
        require(dirname(dirname(__FILE__)) . "/classes/" . $class_name . ".php");
    });

Protip here is `dirname(__FILE__)`

See __DIR__ if >= 5.3

Indeed, slightly cleaner I suppose:

    spl_autoload_register(function($class_name) {
        require(dirname(__DIR__) . "/classes/" . $class_name . ".php");
    });

Which, since he's using an anonymous function, he would be.

Using Ternary Operators you can make a fizzbuzz program in 2 lines or less.

This post reminded me of them and it'll help me neaten up some of my code. Thanks!