|
|
Posted by Oliver Grδtz on 12/05/06 22:53
Adam Scheinberg schrieb:
> 1. Most desirable: the introduction of a new function, print_r_pre()
> which takes the same arguments as print_r().
Yep, and let's introduce var_dump_pre(), var_dump_pre_get_as_string(),
print_r_as_html_table(), print_r_xml()...
Nope, this doesn't make sense. print_r fulfills one function:
transforming a data structure into a string representation describing
the data structure. It does this and nothing more. Mixing it with
specialized formatting code does not add functionality, it takes away
flexibility.
For my part: Yes, I do use print_r() surrounded by <pre> tags. But even
more I use print_r() with its behaviour set to returning a string. Then
I let PHP write this string into a logfile! Outputting debug information
into the browser is a bad habit!! We all do it but it's wrong. And
encouraging bad habits by supplying more convenient functions to do it
is a bad idea.
> 2. Secondly: add a third argument to print_r(), which allows you to use
> print_r($array,0,1) or somesuch.
This is even worse than number 1! First of all it is less
comprehensible, people would start looking "What was that 3rd parameter
for?" and then another parameter means checking for another parameter.
It takes away performance for all cases where the parameter is left in
its default state.
> or
> 3. The least desirable: change the default behavior of this function to
> spit <pre> tags
And breaking tons of existing applications! Sorry, but this is only an
option if you start compiling your own patched version of PHP. The devs
would tear and feather someone suggesting things like that.
In terms of better code it would be a good idea to change the default
behaviour of print_r() to returning a string so less people spill debug
info into the browser. But as I just explained...
OLLi
Navigation:
[Reply to this message]
|