Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120506 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 83812 invoked from network); 1 Jun 2023 23:31:31 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Jun 2023 23:31:31 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7F926180384 for ; Thu, 1 Jun 2023 16:31:27 -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=0.1 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NEUTRAL, T_KAM_HTML_FONT_INVALID,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS19151 66.111.4.0/24 X-Spam-Virus: No X-Envelope-From: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 ; Thu, 1 Jun 2023 16:31:27 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8C53E5C01A3; Thu, 1 Jun 2023 19:31:26 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute2.internal (MEProxy); Thu, 01 Jun 2023 19:31:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type: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=1685662286; x=1685748686; bh=6AaJ+SQIsowyF dpioTfeJVlZRCqSSwDy8Gh+NQisu3g=; b=kAg+1k0zC3t5ERLwfPLzShygbjmbq tCipe5QsgiWzVk7D/b36dnpoWoVsGPeSO3EXtLuxOfbDs00WlQdH1WWukNnUlaoq zvnBqbYP4xmfvx8gAfmOQnyPd8YkM/GyiwK4xW9OIk8QE8S4ZqlSlADZIfvv70nK oEV/rqmz8/jxYZky11AyiptAFYAE/zIolKQk5Z/V9Q5kSMpFp8h2aUoztBFsPBMz ECilUdQbXRqOAMdHfMQCL6y5oM9qjtPoRCpybjxDyONjobbuL51u8na36BVHV5H2 KW3C84Mv4jGEfT0AyuNVGFd3a1tSbbX2AaJzKJlnYMvxkz0IewQhQo/GQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelvddgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvvefutgesrg dtreerreertdenucfhrhhomhepfdevrghsphgvrhcunfgrnhhgvghmvghijhgvrhdfuceo lhgrnhhgvghmvghijhgvrhesphhhphdrnhgvtheqnecuggftrfgrthhtvghrnhepffdtje fhvddtfffffeegvdeggeffgffgffetueelgeefgfelkeeuleekkedvleegnecuffhomhgr ihhnpehphhhprdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheplhgrnhhgvghmvghijhgvrhesphhhphdrnhgvth X-ME-Proxy: Feedback-ID: id4f946ef:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3BC261700089; Thu, 1 Jun 2023 19:31:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-447-ge2460e13b3-fm-20230525.001-ge2460e13 Mime-Version: 1.0 Message-ID: In-Reply-To: <40AD8627-C7EC-4FD9-B47E-8F3A8B8737BE@gmail.com> References: <289E585B-EF8B-4B17-89BE-BE8295FD9FE1@gmail.com> <5FE9216F-A84D-4482-A22E-05A44C2A9A3C@gmail.com> <40AD8627-C7EC-4FD9-B47E-8F3A8B8737BE@gmail.com> Date: Fri, 02 Jun 2023 01:30:58 +0200 To: "Boro Sitnikovski" Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=0262470338e649b4adde51dd1791485a Subject: Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group` From: langemeijer@php.net ("Casper Langemeijer") --0262470338e649b4adde51dd1791485a Content-Type: text/plain On Thu, Jun 1, 2023, at 11:56, Boro Sitnikovski wrote: > Thank you for the suggestion, I like this approach and it's definitely much "safer" than going with an RFC for core directly. > > What are your thoughts on creating a PECL extension called `array_utils` (selling point would be high performance array utils or something), which in the future might contain more than `array_group*`, and the approach would be to cherry-pick those functions that have frequent usage in codebases into core? Or would it be better to stick to a particular/more concrete extension? I don't know. Also, I have no way of knowing if this would work. Although I mail using my php.net email address, and that could convey some authority, I really do not have that. My contribution to PHP is limited to maintaining the PECL ssh2 extension. Most of what I do is merging stuff other people write, keep an eye on bugs, Toss out GitHub issues when they are not relevant or lack real information, and update documentation. Sometimes chances to extension code are required by changes in the PHP interface. Mostly it's all minor stuff, and not much work. If you end up at the stage where you start writing C code, let me know if you think I can be of value to you. I really value other people's contributions in open source projects and enjoy contributing to create a better working development community. I think there can be value in every step that can be taken in developing software. But you should be very realistic in your expectations of code ending up in PHP core. If you can enjoy the process, see the value in the steps in between, if you are prepared to learn stuff that everyone around here already seems to know but somehow is not written down anywhere except in the code of php or other extensions, it is really fun and will bring you insights that are invaluable in working with PHP. Greetings, Casper --0262470338e649b4adde51dd1791485a--