(Using Java terminology): Static methods can be associated with static members (members of the class object). If the methods don't access static members (nor IO resources or anything else that could change state), of if those members are final primitives or immutable objects (essentially constants), then such static methods could be called functions, but in general, because they potentially could access the class object's members, they're usually called static methods.
In order to count as a function, a method must be independent of any state; it must not cause any side effects nor be affected by any side effects. When called with specific parameters, it must always return the same result. Otherwise it's not a pure function.
That is, the following area is a function:
class MyClass {
static final double pi = 3.14;
static double area(double r) {
return pi * r * r;
}
}
while the following getCallCount is not a function:
class MyClass {
static int callCount = 0;
static int getCallCount {
return ++callCount;
}
}
In general, mutable (non-final) static members should be used with caution - someone would say that they should not be used at all - because they make a global state to the program, which likely turns out to be a bad design choice in the long run. There are exceptions, but be careful...
You don't even need static members to make static non-functions: System.nanoTime() is definitely not a pure function (because it returns different value on successive calls), even though it only accesses the computer's clock, not any static members.
Confusingly enough, you could also make non-static pure functions:
class MyClass {
final double pi = 3.14;
double area(double r) {
return pi * r * r;
}
}
Now, although not static any more, area is still a pure function: it doesn't touch anything that could change. The fact that you would have to create an instance of MyClass to access area doesn't reduce its "functionness". Indeed, one could argue that this kind of pure functions should always be made static.
I wouldn't do the second approach as the parameters aren't named.
A well-written essay on describing how a template system should work is coming from Parr, it's often quoted by people writing template systems and/or web-mvc frameworks.
Personally, what I usually prefer is to implement an ArrayObject class with a properties array, and the template would refer to $this->propertyName, which in fact would be the template object's $this->property['name']. This could be also achieved simply by using __set and __get, so:
class Template {
private $_scriptPath=TEMPLATE_PATH;//comes from config.php
public $properties;
public function setScriptPath($scriptPath){
$this->_scriptPath=$scriptPath;
}
public function __construct(){
$this->properties = array();
}
public function render($filename){
ob_start();
if(file_exists($this->_scriptPath.$filename)){
include($this->_scriptPath.$filename);
} else throw new TemplateNotFoundException();
return ob_get_clean();
}
public function __set($k, $v){
$this->properties[$k] = $v;
}
public function __get($k){
return $this->properties[$k];
}
}
and a template would look like:
<html>
<head>
<title><?=$this->title?></title>
</head>
<body>Hey <?=$this->name?></body>
</html>
and invoking it would look like:
$view = new Template();
$view->title="Hello World app";
$view->properties['name'] = "Jude";
echo $view->render('hello.inc');
As far as I remember, this is how the old Symfony 1.x and the Zend_View template engines look like, and for me it's fine.
Best Answer
No difference at all. If you google for it, you can see that somewhere it is defined as function templates and somewhere as template function.
Your understanding was correct.