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
For MySQL 5.0.3 and higher, you can use BIT
. The manual says:
As of MySQL 5.0.3, the BIT data type is used to store bit-field
values. A type of BIT(M) enables storage of M-bit values. M can range
from 1 to 64.
Otherwise, according to the MySQL manual you can use BOOL
or BOOLEAN
, which are at the moment aliases of tinyint(1):
Bool, Boolean: These types are synonyms for TINYINT(1). A value of
zero is considered false. Non-zero
values are considered true.
MySQL also states that:
We intend to implement full boolean
type handling, in accordance with
standard SQL, in a future MySQL
release.
References: http://dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html
Best Answer
To answer your concerns:
MySQL >= 5.1.17 (or >= 5.1.21 for the
PREPARE
andEXECUTE
statements) can use prepared statements in the query cache. So your version of MySQL+PHP can use prepared statements with the query cache. However, make careful note of the caveats for caching query results in the MySQL documentation. There are many kinds of queries which cannot be cached or which are useless even though they are cached. In my experience the query cache isn't often a very big win anyway. Queries and schemas need special construction to make maximum use of the cache. Often application-level caching ends up being necessary anyway in the long run.Native prepares doesn't make any difference for security. The pseudo-prepared statements will still escape query parameter values, it will just be done in the PDO library with strings instead of on the MySQL server using the binary protocol. In other words, the same PDO code will be equally vulnerable (or not-vulnerable) to injection attacks regardless of your
EMULATE_PREPARES
setting. The only difference is where the parameter replacement occurs--withEMULATE_PREPARES
, it occurs in the PDO library; withoutEMULATE_PREPARES
, it occurs on the MySQL server.Without
EMULATE_PREPARES
you may get syntax errors at prepare-time rather than at execute-time; withEMULATE_PREPARES
you will only get syntax errors at execution time because PDO doesn't have a query to give to MySQL until execution time. Note that this affects the code you will write! Especially if you are usingPDO::ERRMODE_EXCEPTION
!An additional consideration:
prepare()
(using native prepared statements), so aprepare();execute()
with native prepared statements may be a little slower than issuing a plain textual query using emulated prepared statements. On many database systems the query plan for aprepare()
is cached as well and may be shared with multiple connections, but I don't think MySQL does this. So if you do not reuse your prepared statement object for multiple queries your overall execution may be slower.As a final recommendation, I think with older versions of MySQL+PHP, you should emulate prepared statements, but with your very recent versions you should turn emulation off.
After writing a few apps that use PDO, I've made a PDO connection function which has what I think are the best settings. You should probably use something like this or tweak to your preferred settings: