Hi there,
we encountered small annoyances over time which could be easy to fix but would
break tests.
Why does this matter? While it is easy to fix the PHP test suite they could
potentially affect other projects' code, most probably tests.
Here are the two things on our current list:
Stack traces:
==========
Stack traces for certain constructs do not include the exact location in the
stack frame:
$a[(object)null] = 1;
$e->getTrace() => [] # <-- no stack trace
while for
file(); / file(null);
$e->getTrace() => [ ["file"]=> .. ].
The change would probably be something like removing one line
ptr = ptr->prev_execute_data;
In Zend/zend_builtin_functions.c
The BC impact Is that stack traces may contain an additional entry which is
used in a lot of tests.
Work-around: Our solution right now is to manually check in the exception
handler whether $e->getFile() / $e->getLine() is already contained in
$e->getTrace()[0] and otherwise add it to have uniform stack traces. Works, but
ugly :-)
Indentation in var_export:
====================
The indentation for
var_export((object)[(object)[]]);
is off by one for nested structures:
(object) array(
'0' => # <-- extra space before index
(object) array(
and the fix would be to change
buffer_append_spaces(buf, level + 2)
to
buffer_append_spaces(buf, level + 1)
in ext/standard/var.c
This breaks about 60 PHP tests relying on the var_export format.
We were hoping for a new function mitigating this issue but
https://wiki.php.net/rfc/readable_var_representation
<https://wiki.php.net/rfc/readable_var_representation> seems to get rejected so
the issue remains :-)
---
Is there any way something like there things could/should be tackled for a
future PHP version?
I'm torn because of the impact vs. benefit of the improvements.
- Chris
