Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124300 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 4D8F11A009C for ; Mon, 8 Jul 2024 23:42:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720482225; bh=nmivNw5QOH4SF38juP2K8SKbPUQKwboZAseKEcV1YsA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FdAY+QSVFwNEAK3vMeuSNlPZ77hha0wrrpa1Q1AAV9TaNBdSBgP5uatb8O0FGZZsd EoBRydx76EIYRHBvp3H19aSseThb70FiQbjSMadniwQXQNrxZZJV5NV2ztB55cl8e4 8Pl0EEFWHY7jNCp2Lo6rXxeQaG8OxxOU73ycrlKxERBFrYJhPGINpFcan4rdl7NDzr N0XiwSxoI77eRFnz6gb3X/FNk63Ap8YNrXW0IPZ32egkhQ4gayzthP4/WBQSDKOb6o fS6KHwmDpNpULqh4OS8VIpKXuMYbzXySeTUzfoGOICcBfzT+JJqrpKJcev9jVvBnAp +0Ecu7LIVa4eg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 54ECA180072 for ; Mon, 8 Jul 2024 23:43:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 8 Jul 2024 23:43:44 +0000 (UTC) Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-4f2e147ee98so1410563e0c.0 for ; Mon, 08 Jul 2024 16:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720482139; x=1721086939; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nmivNw5QOH4SF38juP2K8SKbPUQKwboZAseKEcV1YsA=; b=PgHI6Rpij24gq1FCSlYxTwCCzIUCZ7nIrIHcgaj1ewzbOlQVsXZaCKrYcgO/Ma2WG8 ieL5kSTASi7DnnHbvGOl6RCSs3fGnPQj3J4wo7oLVc2bKvf964zPlwLtA5uz27wHqOwe hjTlspki0dieLevSVqGeBP5DPn7FuEHOIMb4DYSHksjqx2w6SD1vop0nPmJOU4rZh6i8 8vfDhFYegZZefw28jA8XhngvzISSQ109URfm3xc75QN7v4nQuBBnzmvnRg45rwjLxqJP 892pDjWanvJwDzuwEgmgLWEHjXagHdakBgFVl+LVtj6o2PgTuoHqaxbV6+ekea5loEpe OzMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720482139; x=1721086939; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nmivNw5QOH4SF38juP2K8SKbPUQKwboZAseKEcV1YsA=; b=eEQ1ELebQicyz1olFjMAvDHJfM06ESOB9gLcMY7CwuAD5L3JC/tjsciOmteHZ7prqq /iGO6OQDM1fJ1mlCQOOdNl2vpU0X8UFl3ndpka3TZilj3maz7PvGhrrUTZiGJ6TZvpc3 0w8rVvrUmHWdgAIrHOzGBVqEd9HaCkwZsDyWdVmkJ8Di8CYVstgWNQrhCFUFgHZYeHGo XBZsS6wVpCrrmAFYSKdghYb+3UVouRkMqxtxqX1pyDZR18j6jpZHqYYAp12PDQdwhpyX BJjV0z5eMzdadvb7n8EUnalN/EmfcJcrPfJIVGqQm/NKU1EvhPb+ZXNmwV2PUr33hhut J0bQ== X-Forwarded-Encrypted: i=1; AJvYcCUflelrEAZlyiFoK0t2ED9eQWQYWf10ZU31iYlBq0y3cHzQ2GeKx0m4I6ElGcZgAtuFRj83v73U66w3Q1k6GR/azAb/ZdQxnw== X-Gm-Message-State: AOJu0YxYMMVsfBMGRerAVVmyvtth5e+jZiE6FUyc5vj0H8gRsBaX2ge9 SjPyHcV10B/U20Bjp5yyalnXVtmC/Et/7FT3cvHxOdqgipIzD3xv9aUd9LUWiH14WS4XGDdEtMj 6IuWx/Q4EYQ27gaDl8LqqlA5eQAYhUg== X-Google-Smtp-Source: AGHT+IHwrtLTIo5zGogb4nNNJHwIp6GjP+BRKiuWEtXK5p5dNpAZN9sDs4aMM3gUHYw2Sj2uMm27RLovXW4+/+XFUWE= X-Received: by 2002:a05:6122:4109:b0:4d3:36b9:2c26 with SMTP id 71dfb90a1353d-4f33f31b0abmr1261837e0c.14.1720482137517; Mon, 08 Jul 2024 16:42:17 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <66420855-9900-48a8-9964-b9dda81a8bdc@bastelstu.be> In-Reply-To: Date: Mon, 8 Jul 2024 20:42:06 -0300 Message-ID: Subject: Re: [PHP-DEV] [RFC][Discussion] Enhance JSON error messages To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: "Gina P. Banyard" , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000a634a0061cc4f604" From: dev.juan.morales@gmail.com (juan carlos morales) --000000000000a634a0061cc4f604 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El El dom, 30 de jun. de 2024 a la(s) 11:52, juan carlos morales < dev.juan.morales@gmail.com> escribi=C3=B3: > > > El El dom, 30 de jun. de 2024 a la(s) 11:15, Tim D=C3=BCsterhus < > tim@bastelstu.be> escribi=C3=B3: > >> 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=C3=BCsterhus > > >> > 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 > --000000000000a634a0061cc4f604 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


El El dom, 30 de jun. de 2024 a la(s) 11:52, juan carlos mo= rales <dev.juan.morales@gm= ail.com> escribi=C3=B3:


El El dom, 30 de jun. de 2024 a la(s) 11:15, Tim D=C3=BCsterhus &= lt;tim@bastelstu.be> escribi=C3=B3:
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=C3=BCsterhus
=

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 t= hat having better error messages is always welcome but at the moment are di= fferent postures about having

1) enhanced error message
2) have a new functi= on with better data

3) h= aving both=C2=A0


At the moment the mentioned pull request has both

But i need to understand WHA= T are we going to keep. And in case an RFC is needed then i will make it.

Please advice=C2=A0
=

Thanks=C2=A0
--000000000000a634a0061cc4f604--