Re: Proposal: short_var_export($value, bool $return=false, int $flags=0)

Hi Nikita, > The formatting of var_export is certainly a recurring complaint, and previous discussions were > not particularly open to changing current var_export behavior, so adding a new function seems to be > the way to address the issue (the alternative would be to add a flag to var_export). > > I like the idea of the "one line" flag. Actually, this is the main part I'm > interested in :) With the one line flag, this produces the ideal formatting for PHPT tests that want > to print something like "$v1 + $v2 = $v3". None of our current dumping functions are > suitable for this purpose (json_encode comes closest, but has edge cases like lack of NAN support.) > > Some note: > * You should drop the $return parameter and make it always return. As this is primarily an >export and not a dumping function, printing to stdout doesn't make sense to me. It seems inconsistent and prone to bugs when refactoring (e.g. converting to string and not using the result) to have two functions named var_export where one prints by default and the other doesn't, but otherwise . Changing to a different name entirely would solve that, such as var_repr(), var_representation(), serialize_[value_]as_php_snippet(), etc. > * For strings, have you considered printing them as double-quoted and escaping more >characters? This would avoid newlines in oneline mode. And would allow you to escape more control >characters. I also find the current '' .. "\0" . '' format for >encoding null bytes quite awkward. I'd considered that but wasn't sure if anyone else would want that - I also found it annoying for \0 and \n, as well as other control characters (0x00-0x1f, e.g. \r\t) > * I don't like the short_var_export() name. Is "short" really the primary >characteristic of this function? Both var_export_pretty and var_export_canonical seem better to me, >though I can't say they're great either. I will refrain from proposing real_var_export() >... oops :P Potentially not shorter with the extra backslash and the potential for switching to "\$var\0\ntest\\" for string encoding. var_representation($var, int $flags=0) seems clearer Thanks, Tyson