PHP "require" Performance

Performance Talk by Rasmus Lerdorf http://vimeo.com/12416792 (skip to 14:30)

Right, and there's a case for that in languages that need a template library, as well. In some cases, you want to re-render a template for some other place in the output, and in other cases, you'd want to use a previously cached rendered template, and both of those cases are useful.

So, I agree that the distinction between the cases is the result of PHP being both a full programming language and a built-in templating language. I don't view this (in and of itself) as a bad thing, though I would quibble with the exact implementation, which is how it is for historical reasons.

When the problem is framed thus, most people would recognize that the solution to that problem is a better understanding on the part of the programmer of the flow of control inside his/her application.

Since you've already agreed that having the option for rerendering is a feature of including templating as a core feature, it seems like this statement is equivalent to declaring that templating should never be a core feature of a programming language. It's less about the flow of control and more about whether the result is cached. Even programmers who have a good understand of their programs' flow of control occasionally find memoization useful. :)

A language whose maintainers decided that, in the fifth major release, `goto` needed to be added is not getting better. Nor is one whose maintainers rationalize the choice of backslash as a third, distinct scope resolution operator -- instance-attribute, class-attribute, and now namespace-member.

The sheer number of fails with PHP warrants the 'good language' treatment. The fact that,

  08 === 0

First, it's important to understand that include/require_once is useful in PHP because of a particular pattern -- include/require the files containing classes and functions I need; these statements are placed at the top of every script that needs those definitions. It's an error in PHP to declare the same function twice (to redeclare). So if you include script A and B, and both depend on C, then you have to use require_once in A and B when they call in C. This way, anyone calling in both A and B won't trigger a redeclaration error.

This use case is not relevant to people using the statements to pull in templates, because you would deliberately place the require statement where you needed it. Someone using the same partial template in the header of a page and in the footer of a page would not care if the template had been invoked before -- "place this in the footer unless you already placed it somewhere else in the document (or even if you simply included it and threw it away, or emailed it to someone, or anything else at all)" would be a very poorly written template.

So what we have is the case that a set of processing scripts all include the same file at the top and this could potentially trigger redeclaration errors. So instead of addressing the fact that the interpreter cannot distinguish a common pattern (multiple inclusion) from something that really isn't even an error (redeclaration), we have four statements that serve very minor variations of the same function.

There are two binary choices here: require or include and once or not once. The distinction between include and require is totally unnecessary -- in what case would you want to optionally include another file, but not even receive notification or change your behavior depending on whether the file was able to be included? The _once distinction is only a guard against redeclaration, and it's beyond me why it matters that something was declared multiple times -- or why the programmer needs to count the number of inclusions.

Ideally, calling in a template would be different from calling in essential definitions, and would be treated differently.

BTW in Python, the import statement is idempotent -- importing multiple times has the same effect as importing once.