Just like the &
and &&
operator, the double Operator is a "short-circuit" operator.
For example:
if(condition1 || condition2 || condition3)
If condition1 is true, condition 2 and 3 will NOT be checked.
if(condition1 | condition2 | condition3)
This will check conditions 2 and 3, even if 1 is already true. As your conditions can be quite expensive functions, you can get a good performance boost by using them.
There is one big caveat, NullReferences or similar problems. For example:
if(class != null && class.someVar < 20)
If class is null, the if-statement will stop after class != null
is false. If you only use &, it will try to check class.someVar
and you get a nice NullReferenceException
. With the Or-Operator that may not be that much of a trap as it's unlikely that you trigger something bad, but it's something to keep in mind.
No one ever uses the single &
or |
operators though, unless you have a design where each condition is a function that HAS to be executed. Sounds like a design smell, but sometimes (rarely) it's a clean way to do stuff. The &
operator does "run these 3 functions, and if one of them returns false, execute the else block", while the |
does "only run the else block if none return false" - can be useful, but as said, often it's a design smell.
There is a Second use of the |
and &
operator though: Bitwise Operations.
Short Answer
Use $this
to refer to the current
object. Use self
to refer to the
current class. In other words, use
$this->member
for non-static members,
use self::$member
for static members.
Full Answer
Here is an example of correct usage of $this
and self
for non-static and static member variables:
<?php
class X {
private $non_static_member = 1;
private static $static_member = 2;
function __construct() {
echo $this->non_static_member . ' '
. self::$static_member;
}
}
new X();
?>
Here is an example of incorrect usage of $this
and self
for non-static and static member variables:
<?php
class X {
private $non_static_member = 1;
private static $static_member = 2;
function __construct() {
echo self::$non_static_member . ' '
. $this->static_member;
}
}
new X();
?>
Here is an example of polymorphism with $this
for member functions:
<?php
class X {
function foo() {
echo 'X::foo()';
}
function bar() {
$this->foo();
}
}
class Y extends X {
function foo() {
echo 'Y::foo()';
}
}
$x = new Y();
$x->bar();
?>
Here is an example of suppressing polymorphic behaviour by using self
for member functions:
<?php
class X {
function foo() {
echo 'X::foo()';
}
function bar() {
self::foo();
}
}
class Y extends X {
function foo() {
echo 'Y::foo()';
}
}
$x = new Y();
$x->bar();
?>
The idea is that $this->foo()
calls the foo()
member function of whatever is the exact type of the current object. If the object is of type X
, it thus calls X::foo()
. If the object is of type Y
, it calls Y::foo()
. But with self::foo(), X::foo()
is always called.
From http://www.phpbuilder.com/board/showthread.php?t=10354489:
By http://board.phpbuilder.com/member.php?145249-laserlight
Best Answer
The
HTTP_HOST
is obtained from the HTTP request header and this is what the client actually used as "target host" of the request. TheSERVER_NAME
is defined in server config. Which one to use depends on what you need it for. You should now however realize that the one is a client-controlled value which may thus not be reliable for use in business logic and the other is a server-controlled value which is more reliable. You however need to ensure that the webserver in question has theSERVER_NAME
correctly configured. Taking Apache HTTPD as an example, here's an extract from its documentation:Update: after checking the answer of Pekka on your question which contains a link to bobince's answer that PHP would always return
HTTP_HOST
's value forSERVER_NAME
, which goes against my own PHP 4.x + Apache HTTPD 1.2.x experiences from a couple of years ago, I blew some dust from my current XAMPP environment on Windows XP (Apache HTTPD 2.2.1 with PHP 5.2.8), started it, created a PHP page which prints the both values, created a Java test application usingURLConnection
to modify theHost
header and tests taught me that this is indeed (incorrectly) the case.After first suspecting PHP and digging in some PHP bug reports regarding the subject, I learned that the root of the problem is in web server used, that it incorrectly returned HTTP
Host
header whenSERVER_NAME
was requested. So I dug into Apache HTTPD bug reports using various keywords regarding the subject and I finally found a related bug. This behaviour was introduced since around Apache HTTPD 1.3. You need to setUseCanonicalName
directive toon
in the<VirtualHost>
entry of theServerName
inhttpd.conf
(also check the warning at the bottom of the document!).This worked for me.
Summarized,
SERVER_NAME
is more reliable, but you're dependent on the server config!