Re: [PHP-DEV] Re: [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects
wt., 21 lip 2020 o 07:07 tyson andre napisał(a):
> > Can you give an example of an internal stack frame?
>
> A stack frame that was created by a PHP internal function instead of by
> userland code, i.e. one without a file in the frame.
> Related to
> https://github.com/php/php-src/pull/5820#pullrequestreview-452080212
>
>
> ```
> php > array_map(fn() => $GLOBALS['x'] = StackFrame::getTrace()[0], [2]);
> php > var_export($x);
> StackFrame::__set_state(array(
>'file' => NULL,
>'line' => NULL,
>'function' => '{closure}',
>'class' => NULL,
>'type' => NULL,
>'object' => NULL,
>'object_class' => NULL,
>'closure' => NULL,
>'args' =>
> array (
> 0 => 2,
> ),
> ))
> ```
>
The RFC has been adjusted regarding the nullability of file and line
properties and related getter methods.
Is there anything else stopping it from getting up to the vote?
Cheers,
Michał
Re: [PHP-DEV] Re: [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects
> Can you give an example of an internal stack frame?
A stack frame that was created by a PHP internal function instead of by
userland code, i.e. one without a file in the frame.
Related to https://github.com/php/php-src/pull/5820#pullrequestreview-452080212
```
php > array_map(fn() => $GLOBALS['x'] = StackFrame::getTrace()[0], [2]);
php > var_export($x);
StackFrame::__set_state(array(
'file' => NULL,
'line' => NULL,
'function' => '{closure}',
'class' => NULL,
'type' => NULL,
'object' => NULL,
'object_class' => NULL,
'closure' => NULL,
'args' =>
array (
0 => 2,
),
))
```
Regards,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects
Hi Tyson, wt., 21 lip 2020 o 06:54 tyson andre napisał(a): > Hi Michał Marcin Brzuchalski, > > At the time of writing, the documentation in > https://wiki.php.net/rfc/stack-frame-class#stackframe_class is also > inconsistent with the implementation. > `public readonly string $file;` is not actually read only in the > implementation in the GitHub PR. It can be overwritten or deleted with > `$frame->file = 'newfile.php';` > or `unset($frame->file);`. > I'd guess this is expressing the desired way that StackFrame instances > would be used by PHP code, > but that seems confusing because some properties of other internal classes > are actually effectively read only due to providing magic getter APIs. > (Also see my previous comment about ArrayAccess inconsistencies) > Dropping the readonly from the RFC is one possible way to clarify that. > The readonly was dropped in the RFC to meet the implementation similar to PhpToken where a developer is free to modify all properties. Cheers, Michał
Re: [PHP-DEV] Re: [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects
Hi Tyson,
wt., 21 lip 2020 o 04:27 tyson andre napisał(a):
> ...
> I had some comments on the implementation in
> https://github.com/php/php-src/pull/5820#pullrequestreview-452045885
>
Most of these comments can be worked upon the next days in the meantime.
> - How much does this change elapsed time in typical use cases? This had
> completely skipped my mind when I saw this RFC, but I'd generally assume
> that stack traces aren't kept along for longer than needed to process them,
> and that most stack traces would be at most hundreds of frames in typical
> applications. So I'd consider CPU time elapsed more important than RAM.
>
The current implementation works similarly as original one which instead of
creating an array creates an object of StackFrame.
In general use of resources depends on programming style, amount of
rethrows etc. Some use exceptions inappropriately and keep the objects
living for a significant time etc.
> I'd had similar issues with the tradeoffs in PhpToken (and forgot).
> Those issues were that the applications using the array would use less
> memory and be faster if I used the returned array multiple times, but less
> so if I only processed the array once and immediately freed it.
> PHP also seems faster at fetching dimension from arrays than properties
> from objects.
>
> Still, though, this might help with a bit with developer productivity
> (e.g. IDEs being better at inferring types of $frame->getFile() in some
> cases, or providing help text for the method), or in being able to check
> types when passing individual frames
> - I found a bug: The ArrayAccess magic methods are implemented, but not
> the real methods.
>
This can be fixed, PR provides an initial implementation which can be
improved in the next days.
> - I found some memory leaks, possibly related to tracking argument arrays
> in the object being stored
>
> - Casting getFile() to the empty string is unexpected for me
> ($frame['file'] and $frame->file are null in the implementation).
> - Forbidding modification/deletion on the ArrayAccess magic API (e.g.
> `$frame['trace'] = ...`)
> seems inconsistent when modification and deletion are allowed through
> the real properties,
> (and throwing there may affect code written to process the array
> returned by Throwable->getTrace())
>
This can be adjusted to meet 99% compatibility with current array frames,
the only limitation I would see here would be the inability to create
properties dynamically.
> - The typed property default was incompatible with the typed property
> declaration (`class StackFrame { string $file = null; /*...*/}` for
> internal stack frames)
>
Can you give an example of an internal stack frame?
Cheers,
Michał
Re: [PHP-DEV] Re: [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects
Hi Michał Marcin Brzuchalski,
At the time of writing, the documentation in
https://wiki.php.net/rfc/stack-frame-class#stackframe_class is also
inconsistent with the implementation.
`public readonly string $file;` is not actually read only in the implementation
in the GitHub PR. It can be overwritten or deleted with `$frame->file =
'newfile.php';`
or `unset($frame->file);`.
I'd guess this is expressing the desired way that StackFrame instances would be
used by PHP code,
but that seems confusing because some properties of other internal classes are
actually effectively read only due to providing magic getter APIs.
(Also see my previous comment about ArrayAccess inconsistencies)
Dropping the readonly from the RFC is one possible way to clarify that.
```
final class StackFrame implements ArrayAccess
{
public readonly string $file;
public readonly int $line;
```
The first time I've compiled or looked at the implementation and RFC document
in detail was this evening, out of a curiosity of how it worked
and to look into the performance impact to expect,
after seeing the vote announcement this morning.
> Sorry for the late comment - I'd been busy/occupied with various other things
> and this RFC fell off my radar
Regards,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects
Hi Michał Marcin Brzuchalski,
> Heads up, I plan to open the vote tomorrow morning.
Sorry for the late comment - I'd been busy/occupied with various other things
and this RFC fell off my radar,
and I'd assumed that anything I'd end up noticing when looking at the RFC
would have already been pointed out by other reviewers.
(In general, I've only reviewed or locally compiled the code of a small
fraction of recent RFCs mentioned on the mailing list.)
I had some comments on the implementation in
https://github.com/php/php-src/pull/5820#pullrequestreview-452045885
- How much does this change elapsed time in typical use cases? This had
completely skipped my mind when I saw this RFC, but I'd generally assume that
stack traces aren't kept along for longer than needed to process them, and that
most stack traces would be at most hundreds of frames in typical applications.
So I'd consider CPU time elapsed more important than RAM.
I'd had similar issues with the tradeoffs in PhpToken (and forgot). Those
issues were that the applications using the array would use less memory and be
faster if I used the returned array multiple times, but less so if I only
processed the array once and immediately freed it.
PHP also seems faster at fetching dimension from arrays than properties from
objects.
Still, though, this might help with a bit with developer productivity (e.g.
IDEs being better at inferring types of $frame->getFile() in some cases, or
providing help text for the method), or in being able to check types when
passing individual frames
- I found a bug: The ArrayAccess magic methods are implemented, but not the
real methods.
- I found some memory leaks, possibly related to tracking argument arrays in
the object being stored
- Casting getFile() to the empty string is unexpected for me ($frame['file']
and $frame->file are null in the implementation).
- Forbidding modification/deletion on the ArrayAccess magic API (e.g.
`$frame['trace'] = ...`)
seems inconsistent when modification and deletion are allowed through the
real properties,
(and throwing there may affect code written to process the array returned by
Throwable->getTrace())
- The typed property default was incompatible with the typed property
declaration (`class StackFrame { string $file = null; /*...*/}` for internal
stack frames)
With the feature freeze nearby, more of a heads up would have been useful.
Aside: The guidelines in https://wiki.php.net/rfc/howto have been followed,
but I think it'd be useful for those guidelines to say "consider *at least* one
days heads up mail on the mailing list" instead of "consider one days" to avoid
cases where review comments are made on short notice.
Normally, any issues found the day before voting starts would have more time to
reschedule the vote to be addressed.
- I don't know how amendments to the howto get proposed or decided on
Regards,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On 20/07/2020 16:58, Michael Wallner wrote: Distilled down, I just cannot see any huge benefit out of a (or two) root namespace(s). As a project we rightfully own the root namespace, and putting everything beneath PHP just doesn't make any sense to me. You cannot just "own" the root namespace if you want to use namespaces yourself, which we will, it's inevitable, the number of classes and interfaces increases more and more each release. So either you fake namespaces e.g. PhpToken or you trample on userland \Tokenizer. There is one solution to this, and that is to have a vendor namespace for the PHP project itself, naturally the one that is reserved, \PHP. There's a very good reason modern language frameworks claim a couple of root level namespaces, e.g. .NET it's System.* and Microsoft.*, for Java it's java.* -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][DISCUSSION] debug_backtrace alternative as an array of StackFrame objects
Hi Internals, Heads up, I plan to open the vote tomorrow morning. Cheers, Michał Marcin Brzuchalski wt., 7 lip 2020 o 22:46 Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> napisał(a): > Hi internals, > > following recently added alternative to `token_get_all()` in form of a > dedicated class `PhpToken` > I've made a similar proposal for collecting stack traces by introducing > `StackFrame::getTrace()` > and `StackFrame` which replaces array with keys and values known from > `debug_backtrace()`. > > To compete with easier adoption `StackFrame` implements `ArrayAccess` > giving identical API > to `debug_backtrace()`. > > A test script with deep recursion up to 1M frames uses 50% less memory > than `debug_backtrace()`. > > The RFC is described here https://wiki.php.net/rfc/stack-frame-class > It includes implementation of PoC and tests. > > Cheers, > Michał Marcin Brzuchalski >
Re: [PHP-DEV] [VOTE] Named arguments
On Fri, 10 Jul 2020 at 09:42, Nikita Popov wrote: > Hi internals, > > I have opened voting on the named arguments RFC: > https://wiki.php.net/rfc/named_params > I see this vote is currently running close to the super-majority threshold. To those of you whose main concern is the need for libraries to consider backwards compatibility of parameter names, I wanted to point to Symfony's "compatibility promise" [1] and in particular the general disclaimer on anything marked "@internal". There will always be ways to use a library which the author didn't intend; it would be quite reasonable for a library author to say "I do not promise that calling these methods with named parameters will not break". [1] https://symfony.com/doc/current/contributing/code/bc.html To those of you who feel there are better ways to design APIs to avoid ever needing to skip parameters, it would be great to see some ideas to make those alternatives easier. For instance, if you think parameter objects plus the builder pattern is the right way to go, how can we reduce the boilerplate currently required to define the builder class? Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
On Mon, 20 Jul 2020 at 16:58, Michael Wallner wrote: > Distilled down, I just cannot see any huge benefit out of a (or two) root > namespace(s). As a project we rightfully own the root namespace, and > putting everything beneath PHP just doesn't make any sense to me. > I will ask you the same question I have asked others, but without much response: would you vote Yes to an alternative proposal to officially adopt a policy of _never_ using the PHP\* namespace, to eliminate future debates about when to use it? Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics
Hi Larry! Larry Garfield schrieb am Mi., 24. Juni 2020, 02:30: > Greetings, Internalians. > > *dons flame retardant suit* Thank your for your efforts, but I'm about to cast a negative vote on this policy. Distilled down, I just cannot see any huge benefit out of a (or two) root namespace(s). As a project we rightfully own the root namespace, and putting everything beneath PHP just doesn't make any sense to me. Also, most code more than a handful of files is already vendored, and if not a common idiom I see often used, is a simple 'app' or '' namespace. Closing, just let me ensure that it is not because one of my extensions accidentally provides a class beneath a 'php' namespace. Regards, Mike
Re: [PHP-DEV] Changing default assertion mode to throw exceptions
On Mon, Jul 13, 2020 at 11:37 AM Levi Morrison wrote: > > Hello everyone, > > I'd like to change the default mode of assertion failures to throw. > The current default is to warn. In my opinion this is a bad strategy: > the engine asserted that something that is expected to be true is not, > so executing further is a bad idea. This leaves throwing or bailing > out. I think throwing an exception is better than bailing out, so > that's what I propose. Hello, everyone. It's been a week and I have only heard a bit of positive feedback and no pushback. Anyone else want to reply? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
