El El dom, 30 de jun. de 2024 a la(s) 11:52, juan carlos morales < dev.juan.mora...@gmail.com> escribió:
> > > El El dom, 30 de jun. de 2024 a la(s) 11:15, Tim Düsterhus < > t...@bastelstu.be> escribió: > >> Hi >> >> On 6/30/24 15:43, juan carlos morales wrote: >> > So, what I see here in my shortexperiencie is an RFC with 3 Options >> >> That is not an option. Each RFC needs a clear primary vote that is a >> "Yes/No" vote. >> >> > 1) Enhance the error message we already have >> > >> > 2) keep json_last_error_msg as it is and add a new function >> > json_last_error_info function >> > >> > 3) both >> > >> >> Adjusting error messages to make them better is not something that >> requires an RFC. We do this all the time without an RFC. Here's an >> example PR: https://github.com/php/php-src/pull/14496 >> >> A new json_last_error_info() for easier programmatic access of the >> important bits can still be considered, but would not need an RFC either >> from my point of view. It's a simple and obvious addition. Those can be >> done without an RFC, unless someone complains. >> >> Best regards >> Tim Düsterhus > > >> > Ok , then, i will prepare 2 PRs and lets see what happens then. > > Thanks. > > I will let everybody know When ready > Hello again. Well seems there are different opinions about how to approach this. Everyone agrees that having better error messages is always welcome but at the moment are different postures about having 1) enhanced error message 2) have a new function with better data 3) having both At the moment the mentioned pull request has both But i need to understand WHAT are we going to keep. And in case an RFC is needed then i will make it. Please advice Thanks >
