You may want to check out var_export
— while it doesn't provide the same output as var_dump
it does provide a second $return
parameter which will cause it to return its output rather than print it:
$debug = var_export($my_var, true);
Why?
I prefer this one-liner to using ob_start
and ob_get_clean()
. I also find that the output is a little easier to read, since it's just PHP code.
The difference between var_dump
and var_export
is that var_export
returns a "parsable string representation of a variable" while var_dump
simply dumps information about a variable. What this means in practice is that var_export
gives you valid PHP code (but may not give you quite as much information about the variable, especially if you're working with resources).
Demo:
$demo = array(
"bool" => false,
"int" => 1,
"float" => 3.14,
"string" => "hello world",
"array" => array(),
"object" => new stdClass(),
"resource" => tmpfile(),
"null" => null,
);
// var_export -- nice, one-liner
$debug_export = var_export($demo, true);
// var_dump
ob_start();
var_dump($demo);
$debug_dump = ob_get_clean();
// print_r -- included for completeness, though not recommended
$debug_printr = print_r($demo, true);
The difference in output:
var_export ($debug_export
in above example):
array (
'bool' => false,
'int' => 1,
'float' => 3.1400000000000001,
'string' => 'hello world',
'array' =>
array (
),
'object' =>
stdClass::__set_state(array(
)),
'resource' => NULL, // Note that this resource pointer is now NULL
'null' => NULL,
)
var_dump ($debug_dump
in above example):
array(8) {
["bool"]=>
bool(false)
["int"]=>
int(1)
["float"]=>
float(3.14)
["string"]=>
string(11) "hello world"
["array"]=>
array(0) {
}
["object"]=>
object(stdClass)#1 (0) {
}
["resource"]=>
resource(4) of type (stream)
["null"]=>
NULL
}
print_r ($debug_printr
in above example):
Array
(
[bool] =>
[int] => 1
[float] => 3.14
[string] => hello world
[array] => Array
(
)
[object] => stdClass Object
(
)
[resource] => Resource id #4
[null] =>
)
Caveat: var_export
does not handle circular references
If you're trying to dump a variable with circular references, calling var_export
will result in a PHP warning:
$circular = array();
$circular['self'] =& $circular;
var_export($circular);
Results in:
Warning: var_export does not handle circular references in example.php on line 3
array (
'self' =>
array (
'self' => NULL,
),
)
Both var_dump
and print_r
, on the other hand, will output the string *RECURSION*
when encountering circular references.
You can use the strval()
function to convert a number to a string.
From a maintenance perspective its obvious what you are trying to do rather than some of the other more esoteric answers. Of course, it depends on your context.
$var = 5;
// Inline variable parsing
echo "I'd like {$var} waffles"; // = I'd like 5 waffles
// String concatenation
echo "I'd like ".$var." waffles"; // I'd like 5 waffles
// The two examples above have the same end value...
// ... And so do the two below
// Explicit cast
$items = (string)$var; // $items === "5";
// Function call
$items = strval($var); // $items === "5";
Best Solution
EDIT Didnt see this was tagged Smarty. Disregard my answer if you want a Smarty specific answer.
I wouldn't agree that there is a predominant placeholder format. In general, the format depends on how you handle the translations and that can vary.
Apart from that, it is not uncommon to provide the default language strings as translation labels. For instance, in the Zend Framework manual, this is part of their usage example. Nothing wrong with that if your translation adapter supports that. If it requires IDs, then it's not an option.
Personally, I prefer IDs and try to name them according to their usage in the application, e.g. form.label.login.username or cart.checkout or flashmessage.notice.
Using IDs also provides another layer of separation. Given that texting might not fall into the responsibility of either developer or template designer, it's better to have IDs in your templates.