Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120174 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 27940 invoked from network); 2 May 2023 08:18:46 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 May 2023 08:18:46 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 639941804AA for ; Tue, 2 May 2023 01:18:44 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) (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 ; Tue, 2 May 2023 01:18:43 -0700 (PDT) Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-187b07ad783so3284159fac.0 for ; Tue, 02 May 2023 01:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683015522; x=1685607522; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1qOe9WciAhC/FBX2EupRVrq29GViNcJXvyJmFTM/nbI=; b=WX+IacDC/jgqL/1TF2Jn4qdVDzE6jMo81kGLFdKxQl9tLRf/3rX14s6TQqyrTvqeIU gsYgVHIoSAt6Sp+hGx5hYthcwMQ2hqmRsOl8xKeemBzi6pAEu8ckgU1G+Yv9CNBMGmcX SfSqQjavKGHI66SwyMzBW5w8oP+up5fIFWZwaluuXpWTzEFa4olz5UxhzHXYTaFVjhhc dcHwdHKp6o0ez562j2YGZs5+lyPbKtM7dhzhcKP310iZPmQLJFMz6VEDvG99K8PzjtIc S7wNZ3QfFDuwfIZajaiU684LU92e1ZuoKFOqPe72klifRU7t8zswRy29h+kznAvMYhqN lPkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683015522; x=1685607522; 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=1qOe9WciAhC/FBX2EupRVrq29GViNcJXvyJmFTM/nbI=; b=OK6K8oFfJupopsesUcK1QrLvE36P9slNxKGYc26afGddCF0PISQp1Ougg0MifoR/lY RVhBJOIor3HyXknCJOuIkEZU3snLjvmGd0mkpcHytxUHeblID/PY6REUeRddq2WGFwVo 5Y3HU3Ri4kgOrNryEhTtlPQn7KVM/hWYCxjc9kJoQEZsLBomU4HvqM7jV2I7Dq94JGlh UsWYLHjfMwKaAOpXwUFY1xynWJ3aIh/ttehQIoMF7w0YY4MW4ZlK2AunRifuSx7P+Hnk DB4pUjEUBoU/R4RiROQE82kEl+ZQmsJ3z/mgZpNLdABHxEZO8/niBL03n4DVgfBDvg3d /dOQ== X-Gm-Message-State: AC+VfDyj6KVMXfsHJdijrKXS2lVbt/WwE+8vneib6pbMt4/VV6qss3nU KW1v7513X/EU+b9+Ev32JIMZlXtRUHZrNgftGkPARj/5szDCJA== X-Google-Smtp-Source: ACHHUZ5vn5cy3aongC04kSZ6GAftLu6CqW4/EPce3yVGh6T9B5b+xzd21NFSG6o+pcLEb5mz7Xtn0pwOXMKnyeuXyKA= X-Received: by 2002:a05:6870:e901:b0:177:9b62:6b87 with SMTP id l1-20020a056870e90100b001779b626b87mr7289169oan.20.1683015522523; Tue, 02 May 2023 01:18:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 2 May 2023 10:18:31 +0200 Message-ID: To: Kamil Tekiela Cc: PHP Internals List Content-Type: multipart/alternative; boundary="0000000000005f206105fab196a8" Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=) --0000000000005f206105fab196a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kamil, Thank you for your reply, it is pretty much appreciated! I think one year of deprecation is not enough. I believe the functions > that get replacements should be deprecated immediately in PHP 8.3 to > give people two years of deprecation notice. It doesn't make sense to > me to add a replacement but not deprecate the old variant. > Yes, this upgrade path also makes sense to me, and I'm happy to go with it if others don't disagree! Probably my approach would be advantageous if we were earlier in the 8.x lifecycle. > `($rm =3D new ReflectionMethod(explode(=E2=80=9C::=E2=80=9D, $string));) = ` I think you > forgot a splat operator here. > Fixed! > ReflectionProperty::setValue could have an alternative called > ReflectionProperty::setStaticValue. Then there would be no need for > the unused parameter anymore. > Originally, my proposal had this method, but at last I removed it based on Nicolas' suggestions. I think both ways make sense, a single setValue() is probably much easier from the migration point of view, since the suggested alternative is already there in older PHP versions. And it doesn't mean we cannot have a ReflectionProperty::setStaticValue() later on. :) > The overload of array_keys should be replaced with a new function > array_search_all. This overload is little known and very confusing. > Thanks for pointing this out, I'll look into this soon! > > The overload of ldap_exop should just be deprecated. An alternative > already exists and is the preferred way. > I've just included ldap_exop() in the RFC, albeit slightly differently to your suggestion: since this function performs the extended operation synchronously or asynchronously based on whether the $response_data parameter is provided= , we cannot simply deprecate and remove the latter one, because as far as I can understand, synchronous communication is also a valid use-case. So I went with adding an ldap_exop_sync() function. > I wasn't aware that pg_execute has an overload apart from the default > connection one. Could you explain what that overload is? > You are right, as it turned out for me, there is no other overload indeed, so I removed it from the RFC. > stream_context_set_option should get alternative > stream_context_set_option_array. > Thanks for the suggestion! I incorporated this suggestion into the RFC (using the stream_context_set_options name though). What is the last item in Future scope supposed to be, because I think > ReflectionProperty is a typo. > Right, it's now removed. > Why is implode() not mentioned in this RFC? > Because it's not overloaded anymore. :) Even though the manual lists multiple signatures for it, its exact signature is the following: function implode(string|array $separator, ?array $array =3D null): string {= } I'm not sure how much people would miss the possibility to use implode with a single argument ("implode($array)"), but if that's the case, we can add it to the usual PHP 8.3 or PHP 8.4 Deprecations RFC. I wouldn't like to add it to mine, because it's already way too long. Regards: M=C3=A1t=C3=A9 --0000000000005f206105fab196a8--