Hi Rowan, > > If a php developer is learning the language through php's official manual, > > official language reference, or through an online tutorial, > > that would have sections showing the different scalar types, examples > > involving objects and/or arrays, etc. > > Those use var_export/var_dump > > > > https://www.php.net/manual/en/functions.anonymous.php > > https://www.php.net/manual/en/language.types.string.php > > https://www.php.net/manual/en/language.types.boolean.php > > https://www.php.net/manual/en/language.types.object.php > > Every single one of those uses var_dump, and I see no reason why they > should use anything different.
Sorry, I misread your comment as being about the family of debug output functions as a whole. I'd agree var_dump is the most appropriate for these. if the manual depended on printf or `var_export(); echo "\n";` then a developer new to programming might have to read the printf documentation or echo documentation or concatenation documentation first to better understand the examples. If php were to add a `puts()` or `println()` function that would automatically append a newline then that might also work better in tutorials longer-term, e.g. `puts(var_representation($value))`. The fact that php was originally for "personal home pages" may explain why this isn't currently part of the standard library, since newlines are mostly treated like whitespace in most html elements except `<textarea>`, etc. > > The use case of "generate a (short, readable, escaped) representation of a > > variable that can be evaluated" > > is something I'd consider useful enough on its own, a useful primitive in a > > modern programming language > > I guess I just don't agree. I think the use case of "generate a > representation that can be evaluated" is adequately covered by > var_export, the "short" is mostly irrelevant, and the "readable" mostly > opinion-based. The "escaped" sounds useful, but more as an enhancement > to the current function (with a flag, if compatibility is really an > issue) than a ground-up re-design. I had considered that option, but had expected more pushback because of https://github.com/php/php-src/pull/6619#issuecomment-765809096 and the discussion on the prior RFC email threads on improving var_export. 1. Passing too many arguments to var_export would cause a ArgumentCountError or warning before php 8.1 if flags were added to var_export 2. If that approach was used, I'm concerned PHP may indefinitely keep the default behavior of `array (`, `NULL`, etc. in var_export. (changing the default behaviour of var_export significantly may discourage some users from upgrading php due to libraries/applications that depend on it) 3. It is practical to polyfill var_representation for php 8.0 and older and allow applications to use it immediately after 8.1 is released, but less so for var_export. > > I would be in favor of adding string escaping to var_dump, > > but that is a discussion that should be "left out of this" RFC > > as var_dump has a different purpose. > > Sorry, I'm really confused here. On the one hand, most of your examples > are of things that currently use var_dump; on the other hand, you insist > that improving var_dump is a completely unrelated topic. Surely if > var_dump was improved, that would influence the choice of function in > those use cases? You have proposed no mechanism other than string escaping by which var_dump could or should be improved. var_dump accepts a variadic list of objects, so $flags or $options can't be added to it even if you wanted opt-in enhancements like single line representation. As I said earlier, var_dump always prints to stdout, which may get mixed with error handler output or stdout if ob_start() is used.. I don't expect var_dump to be changed in a way that would make the output possible to `eval()`; eval()able output representation is what I'm working on. Regards, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
