Re: [PHP-DEV] Proposal for a RFC

This is only part of a thread. view whole thread
  105615
May 7, 2019 12:22 nikita.ppv@gmail.com (Nikita Popov)
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 > >
  105617
May 7, 2019 12:28 stevenwadejr@gmail.com (Steven Wade)
> 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.
Are you talking about adding a separate function to replace my proposed __toArray() and casting functionality? Or did you mean adding a separate function to add functionality and insight into objects that packages like VarDumper have been using casting to access? -- Steven Wade stevenwadejr@gmail.com
  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