It seems like my code works to check for null if I do
if ($tx)
or
if (isset($tx))
why would I do the second one when it's harder to write?
It seems like my code works to check for null if I do
if ($tx)
or
if (isset($tx))
why would I do the second one when it's harder to write?
${ }
(dollar sign curly bracket) is known as Simple syntax.
It provides a way to embed a variable, an array value, or an object property in a string with a minimum of effort.
If a dollar sign ($) is encountered, the parser will greedily take as many tokens as possible to form a valid variable name. Enclose the variable name in curly braces to explicitly specify the end of the name.
<?php $juice = "apple"; echo "He drank some $juice juice.".PHP_EOL; // Invalid. "s" is a valid character for a variable name, but the variable is $juice. echo "He drank some juice made of $juices."; // Valid. Explicitly specify the end of the variable name by enclosing it in braces: echo "He drank some juice made of ${juice}s."; ?>
The above example will output:
He drank some apple juice. He drank some juice made of . He drank some juice made of apples.
global
is a keyword that should be used by itself. It must not be combined with an assignment. So, chop it:
global $x;
$x = 42;
Also, as Zenham mentions, global
is used inside functions, to access variables in an outer scope. So the use of global
as it is presented makes little sense.
Another tip (though it will not really help you with syntax errors): add the following line to the top of the main file, to help debugging (documentation):
error_reporting(E_ALL);
This thread is abit old but I did some tests relating to the question so I might as well post it:
The testing code (PHP 5.3.3 - CentOS release 6.5 (Final)):
class NonExistant
{
protected $associativeArray = array(
'one' => 'one',
'two' => 'two',
'three' => 'three',
'four' => 'four',
'five' => 'five',
'six' => 'six',
);
protected $numIterations = 10000;
public function noCheckingTest()
{
for ($i = 0; $i < $this->numIterations; $i++) {
$this->associativeArray['none'];
}
}
public function emptyTest()
{
for ($i = 0; $i < $this->numIterations; $i++) {
empty($this->associativeArray['none']);
}
}
public function isnullTest()
{
for ($i = 0; $i < $this->numIterations; $i++) {
is_null($this->associativeArray['none']);
}
}
public function issetTest()
{
for ($i = 0; $i < $this->numIterations; $i++) {
isset($this->associativeArray['none']);
}
}
public function arrayKeyExistsTest()
{
for ($i = 0; $i < $this->numIterations; $i++) {
array_key_exists('none', $this->associativeArray);
}
}
}
The results are:
| Method Name | Run time | Difference
=========================================================================================
| NonExistant::noCheckingTest() | 0.86004090309143 | +18491.315775911%
| NonExistant::emptyTest() | 0.0046701431274414 | +0.95346080503016%
| NonExistant::isnullTest() | 0.88424181938171 | +19014.461681183%
| NonExistant::issetTest() | 0.0046260356903076 | Fastest
| NonExistant::arrayKeyExistsTest() | 1.9001779556274 | +209.73055713%
All the functions are called the same way with via call_user_func()
and timed with microtime(true)
Observations
empty()
and isset()
are the clear winners over the other 2 methods here, the two methods are pretty much tied on performance.
is_null()
performs bad because it needs to lookup the value first, pretty much the same as just accessing the non-existant value $this->associativeArray['none']
, which involves a full lookup of the array.
However, i'm surprised by the performance of array_key_exists()
. Where it is 2 times slower than empty()
and isset()
.
NOTE:
All the functions I've tested have different uses, this benchmark is only here for the most generic use case where you want to quickly check the value in an array. We can go into argument of whether null
should be considered a "value" or simply an indicator of non-existence, but that's another topic. o.o
UPDATE 2017-01-20
Use PHP 7.1
Fixed bug mentioned by @bstoney
$ php -v
PHP 7.1.0 (cli) (built: Dec 2 2016 03:30:24) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies
$ php -a
php > $a = ['one' => 1, 'two' => 2, 'three' => 3];
php > $numIterations = 1000000;
php > $start = microtime(true); for ($i = 0; $i < $numIterations; $i++) { $a['none']; }; echo microtime(true) - $start;
0.43768811225891
php > $start = microtime(true); for ($i = 0; $i < $numIterations; $i++) { empty($a['none']); }; echo microtime(true) - $start;
0.033049821853638
php > $start = microtime(true); for ($i = 0; $i < $numIterations; $i++) { is_null($a['none']); }; echo microtime(true) - $start;
0.43995404243469
php > $start = microtime(true); for ($i = 0; $i < $numIterations; $i++) { isset($a['none']); }; echo microtime(true) - $start;
0.027907848358154
php > $start = microtime(true); for ($i = 0; $i < $numIterations; $i++) { array_key_exists('none', $a); }; echo microtime(true) - $start;
0.049405097961426
What's the point of using them at all? Why i can't just create class with all methods, that i need and then set object of this class as property (i.e. what's the convenience of using protocols)?
A single object can conform to multiple protocols, for example it could be both a UITableViewDelegate
and a UIAlertViewDelegate
. A single class cannot have multiple superclasses (even in languages where this is syntactically legal, we have long known that this creates significant problems, most famously the Diamond Problem).
Who invokes the methods of AppDelegate? Why there is a class for these methods, not a protocol?
The UIApplication
invokes the methods. It is a protocol: UIApplicationDelegate
. There just happens to be a class that conforms to that protocol.
I read, that delegate methods contains words like "did", "will", "should", "become". So why the methods of ViewController named that way? How it is correlating with delegates?
UIViewController
is not a delegate, nor does it have a delegate (well, a transitioning delegate was added in iOS 7, but that doesn't change much). It is a class that is designed to be subclassed. These are methods that are intended to be overridden if you want to know when various events occur. That have similar names because they are called for similar reasons.
I want to point out that everyone's reponse I've read here should have one caveat added:
"isset() will return FALSE if testing a variable that has been set to NULL" (php.net/isset).
This means that in some cases, like checking for a GET or POST parameter, using isset() is enough to tell if the variable is set (because it will either be a string, or it won't be set). However, in cases where NULL is a possible value for a variable, which is fairly common when you get into objects and more complex applications, isset() leaves you high and dry.
For example (tested with PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 17 2008 09:05:31)):
outputs:
Thanks, PHP!