Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118514 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 5618 invoked from network); 26 Aug 2022 14:59:42 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Aug 2022 14:59:42 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C4946180544 for ; Fri, 26 Aug 2022 07:59:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29838 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 26 Aug 2022 07:59:41 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F14C732007F1 for ; Fri, 26 Aug 2022 10:59:39 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute1.internal (MEProxy); Fri, 26 Aug 2022 10:59:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1661525979; x=1661612379; bh=4mCWSThIPjg8BeZzZbH/ZdOnc MGxcZbNJRqwxW6WXT4=; b=Yit+1joRdnUC69tFI/C9JssqiuFQ4S5i45Ku55Klz S5cUxYGBxYaozclWrKbU5QJ6l/5O2vfu0q1/16kgTUJd9klcbAeWDyh6jkcfvwoR IxMEJOXn0WpoV7vifLEy4ugVZ0ziMPwvd0VoSaZw01GxblTpB+Ox2nJWfgLe4Z7j w9H72vStsgO40s9sl/nunBDdzXCNrwR31xc3TFAtev+kTl0BQCyV1ODbvOEvcR+m 5w1RKRTCFE1nTTGbnx6DWhX9ZMLP+Kl6rQy9ylr9APR3KDlAGTU6DUZ36nGN+SKg Sz5F0ndAXObCWbGlHkWrsJqG1vvnCotW3vexoLDiO4zRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1661525979; x=1661612379; bh=4 mCWSThIPjg8BeZzZbH/ZdOncMGxcZbNJRqwxW6WXT4=; b=ohQ+15zTB3iE51Yvq 1kT/V3jz23At1uZY/MNUaS7nvSyczGnZLEFlJCxWjIbLBng+ICaWXhxyViNfu6Ok LJ0FSuSFHbbM9MyEVroTBVFtE9ep2CaI7W8QG9fAT/y0UwTwcQ2tV0FkJq+z/c4H g6m/si5Rop6jx3calQQ1/oCc+ZjpWC7eIiy7lOr4ZetDShWdijx6+4VDx/06zFpW lPWzIA3YYlM7xrVmc61W2fa++hgbkpX2Nxf2nINH/gof8fXsKut+2QyPGcrdDjM+ EEQyQnYsxlO9wB4bRaf7cJpk/Qf/w6swVFq7nG64JBAxEvd849KOcGjcsVAC8YhR 74DVQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdejhedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfnfgr rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg homheqnecuggftrfgrthhtvghrnhepffffffejffdugfegvedviedttedvgfejffefffej leefjeetveehgefhhfdvgfelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1F7EE1700082; Fri, 26 Aug 2022 10:59:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a Mime-Version: 1.0 Message-ID: In-Reply-To: References: <8D53AD5B-7CFC-4820-9EE4-FEB365D327A8@woofle.net> Date: Fri, 26 Aug 2022 09:59:18 -0500 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] RFC json_validate() - status: Under Discussion From: larry@garfieldtech.com ("Larry Garfield") On Fri, Aug 26, 2022, at 4:00 AM, Micha=C5=82 Marcin Brzuchalski wrote: > A `json_decode()` is a substitute that IMO solves 99% of use cases. > If I'd follow your logic and accept every small addition that handles = 1% of > use cases, somebody will raise another RFC > for simplexml_validate_string or yaml_validate and the next > PhpToken::validate. The heuristic I use is that an API should be "reasonably complete" in on= e location. Having a half-assed API in C and the rest left to inconsist= ent and redundant user-space implementations is a terrible API; the same= would apply for a user-space library that is half-assed and leaves the = rest to "someone else to write." Naturally "reasonably complete" is a s= omewhat squishy term, which is why it's a heuristic. By that metric, yes, str_starts_with() and friends absolutely belonged i= n core, because we already have a bunch of string functions and str_star= ts_with() is by a wide margin the most common usage of strpos(). By the same token, yes, json_validate() makes sense to include in the ma= in API, which means in C. If there's a performance benefit to doing so = as well, that makes it an easy sell for me. simplexml_validate_string: I could see the argument there as well, quite= frankly. Unless there is already an equivalently capable option in cor= e, which in this case it sounds like there is. yaml_validate: There is no YAML parser that ships with PHP, so no, this = wouldn't make sense. If at some point in the future PHP added a C-based= YAML extension to the standard distribution, then including a validate = function in that would make sense. (Whether we should include a YAML ex= tension in the standard distribution is an entirely separate question.) PHPToken::validate: Again, PHPToken is in core, so why wouldn't we also = include a validate for it, especially if it's easy to do and logically b= elongs in the same "surface area"? Really, the whole "functions don't belong in C" argument is tired. That= ship sailed decades ago. PHP has a mixed-implementation life, whether = we like it or not. Some APIs and standard lib components are in C, deal= . For those that are or make sense to be, they should be robust and sel= f-contained and complete. For those that aren't, they should be kept ou= t as a set, or added "as a set." That's the granularity where we should= be talking, not the function level. I'm in favor of this RFC. However, I do agree that it should never thro= w, period. Only return a boolean. I'm not sure if JSON_INVALID_UTF8_IG= NORE makes sense either, frankly. That should get corrected before it g= oes to a vote. --Larry Garfield