Re: [PHP-DEV] Proposal for a RFC

This is only part of a thread. view whole thread
  105618
May 7, 2019 12:31 php-lists@koalephant.com (Stephen Reay)
> On 7 May 2019, at 19:22, Nikita Popov ppv@gmail.com> wrote: > > On Tue, May 7, 2019 at 2:20 PM Steven Wade <stevenwadejr@gmail.com> wrote: > >>> I want to weight in with what Marco expressed. I have the very same >> concerns and they are major ones for many use cases. Mine is VarDumper. >>> >>> Please don't do this the way it is described. >> >> >> Is there a way that you'd suggest? First of all, TIL some cool things >> about "(array) $foo" and how VarDumper uses that, so thank you! Secondly, I >> believe the casting syntax is the best user experience and would be a good >> addition to the language, so is there any other way at all to maintain >> something like VarDumper's functionality without using the casting syntax? >> I'd like to find a way to not distrupt too much of what's out there, while >> also adding value to the end user. >> > > We can add a separate function to provide this functionality. We should do > that anyway because it's both clearer and because (array) already requires > some special handling for ArrayObject that could be avoided. > > Nikita > > On Tue, May 7, 2019 at 2:20 PM Steven Wade <stevenwadejr@gmail.com> wrote: > >>> I want to weight in with what Marco expressed. I have the very same >> concerns and they are major ones for many use cases. Mine is VarDumper. >>> >>> Please don't do this the way it is described. >> >> >> Is there a way that you'd suggest? First of all, TIL some cool things >> about "(array) $foo" and how VarDumper uses that, so thank you! Secondly, I >> believe the casting syntax is the best user experience and would be a good >> addition to the language, so is there any other way at all to maintain >> something like VarDumper's functionality without using the casting syntax? >> I'd like to find a way to not distrupt too much of what's out there, while >> also adding value to the end user. >> >> -- >> Steven Wade >> stevenwadejr@gmail.com >> >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>
Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t this type of thing exactly why the `__debugInfo` magic method exists?
  105619
May 7, 2019 12:47 stevenwadejr@gmail.com (Steven Wade)
> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t this type of thing exactly why the `__debugInfo` magic method exists?
I can't speak for the exact reason a library like VarDumper is using casting versus __debugInfo, but in trying to find a substitute this morning, I played with the method you mentioned and found that it can be overwritten by classes and be commanded to not return anything (similar to my __toArray proposal), whereas current functionality prevents overriding casting to an array so casting will always give you insight but users can overwrite __debugInfo and cause unintended effects. I assume that's the reason for not using __debugInfo. -- Steven Wade stevenwadejr@gmail.com
  105620
May 7, 2019 12:52 php-lists@koalephant.com (Stephen Reay)
> On 7 May 2019, at 19:47, Steven Wade <stevenwadejr@gmail.com> wrote: > >> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t this type of thing exactly why the `__debugInfo` magic method exists? > > > I can't speak for the exact reason a library like VarDumper is using casting versus __debugInfo, but in trying to find a substitute this morning, I played with the method you mentioned and found that it can be overwritten by classes and be commanded to not return anything (similar to my __toArray proposal), whereas current functionality prevents overriding casting to an array so casting will always give you insight but users can overwrite __debugInfo and cause unintended effects. I assume that's the reason for not using __debugInfo. > > -- > Steven Wade > stevenwadejr@gmail.com > > >
Right, I understand that it *can* be overridden, but surely if someone’s doing that, its because they want more useful information provided in, e.g. var_dump.
  105621
May 7, 2019 12:57 stevenwadejr@gmail.com (Steven Wade)
> On May 7, 2019, at 8:52 AM, Stephen Reay <php-lists@koalephant.com> wrote: > > >> On 7 May 2019, at 19:47, Steven Wade <stevenwadejr@gmail.com> wrote: >> >>> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t this type of thing exactly why the `__debugInfo` magic method exists? >> >> >> I can't speak for the exact reason a library like VarDumper is using casting versus __debugInfo, but in trying to find a substitute this morning, I played with the method you mentioned and found that it can be overwritten by classes and be commanded to not return anything (similar to my __toArray proposal), whereas current functionality prevents overriding casting to an array so casting will always give you insight but users can overwrite __debugInfo and cause unintended effects. I assume that's the reason for not using __debugInfo. >> >> -- >> Steven Wade >> stevenwadejr@gmail.com >> >> >> > > Right, I understand that it *can* be overridden, but surely if someone’s doing that, its because they want more useful information provided in, e.g. var_dump.
I think that's a good point. If we follow that mentality, then the proposed __toArray and it's subsequent ability to affect array casting isn't a worry too much as the proposal is to only call __toArray if it exists and an object is cast to an array, so if a user manually implements __toArray, then we could assume "they want more useful information provided in, e.g. var_dump." -- Steven Wade stevenwadejr@gmail.com