Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116798 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 52931 invoked from network); 4 Jan 2022 01:16:05 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Jan 2022 01:16:05 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 08EEC1804A7 for ; Mon, 3 Jan 2022 18:23:09 -0800 (PST) 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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS 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-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 3 Jan 2022 18:23:08 -0800 (PST) Received: by mail-lf1-f41.google.com with SMTP id j11so76740764lfg.3 for ; Mon, 03 Jan 2022 18:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x/Dr+79BSPghgoXI4zsGXQa8QVTiVxYPmxjlACofrG0=; b=eByz/B80EtzWJRfahAgfRKRzD5yU41N04DXYYk23Cxxg3bufGXm8CHZKKpFMOegI4k mOUEtsOntEqJEAF+OFN8v2NiBid6xq7d252bTmNWA6pMPzVKb2N+QwFc/8zuG5gX0NNf 6kOA7q96c2nCdInLcksRCZoLRl22EUFXJrT/jYSvVrfJJyM2GJ2XzCdC27tmnEK1Nmp5 +nKfgla+jk+lkXBNCY9cHfjMW09ac4mEOp1S6VY+n3nBFHRZQZqS1jN+tGvT0vKbIf4M ibrjuPr2dsf/SY8e18C0tBhgNE14SxgUq4BKvMwC2vLkt/WGj3Eem2JZsOK5rmB9WG63 dbtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x/Dr+79BSPghgoXI4zsGXQa8QVTiVxYPmxjlACofrG0=; b=17Fc54ejaU/WLa2IjeW6QPf+xjJwFTYOnyyKsZuL2Kwe/XI3vPh/KfitIh0jb0VuT5 30wrfu7Vcu2jJdeHSK9Bgk9YXdf7XE6XQ2RkymTqzvdejLp+/4reYBxTne3wb0RQsKx7 bpgH69F3g4tNRf3LjxyRd76vkJzcpZJk7Zbcz3ypfXy0ZnNHLIdHOl24mEEU3FiR2tjT BiDTveAH2HM+CWQWlPxTBR0VT+LErCOZAHPKpFwwH1oVw4CfZWI+FAFaGClJTyQdDLoK 5/ckQrbNL8FR86jy50vwt7+YQPG8nTNGL5T+k5nDMVJeqFNw10wzXdfSMW/GqvdwdABG e73g== X-Gm-Message-State: AOAM532UAA9/v38i97S3SQArBe/ncQnkR3x59GoIwL1ScnPvKYcU2HRX WO4ACRSTgTjuVkDtkpeLIjrGIcH2C5UrzJF9ii1ovH2WrVA= X-Google-Smtp-Source: ABdhPJygF1eplvS9J6rymBqZIiAONEtxt8EDDfoQyQw7HkWfgV4B8bi0xlnBou7L+zDAgRbHbd42rt6vrXHtkslr9sY= X-Received: by 2002:a05:6512:e84:: with SMTP id bi4mr42984433lfb.39.1641262986868; Mon, 03 Jan 2022 18:23:06 -0800 (PST) MIME-Version: 1.0 References: <3225c921-9b26-d2e0-f76f-45fff6f5a12a@processus.org> <40a1e5fa-396d-d9ef-93ab-6fcfb5054092@processus.org> In-Reply-To: Date: Mon, 3 Jan 2022 18:22:55 -0800 Message-ID: To: Andreas Hennings Cc: Pierre , Larry Garfield , php internals Content-Type: multipart/alternative; boundary="00000000000050bc0b05d4b8515d" Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads From: jordan.ledoux@gmail.com (Jordan LeDoux) --00000000000050bc0b05d4b8515d Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings wrote: > To me it is not surprising that an RFC like this would be controversial. > We could enter a wonderful new era of value objects with operators, > but it is hard to envision that beforehand. > > The best might be to find and advertise with use cases and examples > from other languages. > (as mentioned, I don't really know where to start looking, otherwise I > would have already shared something) > Oh, this was always going to be a controversial RFC. :) Operator overloading is controversial in most languages, even the ones that have it and don't really have problems because of it. It's the kind of feature that doesn't affect most people most of the time, but that all developers end up having a strong opinion about one way or another. I talked about that a little bit in the internals podcast episode I did with Derick. NumPy is probably the absolute best example of this feature being used. NumPy is an absolute killer feature of Python, and drives an enormous amount of the development being done in the language. It could easily be pointed out that NumPy is the equivalent of an extension however, being compiled down and directly hooking into the Python language. NumPy is also not included in the core Python language, though operator overloading *is*, importantly. However, the toolchain for adding NumPy is much easier and consistent than the toolchain for PHP extensions in general, and NumPy didn't have to add overloads themselves as part of the extension (or teach Python devs the rules around using them in general). So as another example, I'll pull up the math libraries in PHP. I maintain a math library myself, but it isn't nearly as widely used as the works by Mark Baker. The mathematical uses have been described here as "niche" and "small". First let's see what Mark has to say about operator overloading (and this RFC specifically): > Likewise, I have libraries for Matrix and Complex Numbers, where this would be an incredibly useful addition.... a similar RFC using magic was proposed 6 years ago, and sadly never made it :-( I hope this time it is accepted, especially as a new keyword feels better than magic - Source: https://twitter.com/Mark_Baker/status/1477957056464359427 The libraries that Mark is referring to, markbaker/matrix and markbaker/complex, have over 105 million installs combined on packagist. (Source: https://packagist.org/?query=markbaker ) > And so would `$lineValue = $unitPrice * $quantity;` work fine, with less words to read... and people who don't understand operator precedence would have problems with more complex mathematical formulae whether it was operator overloading or method name - Source: https://twitter.com/Mark_Baker/status/1478137583989309440 > But why shouldn't it be `==`... these are valid use cases for a comparison; equally, vector additions ($vector1 + $vector2) are quite commonplace in mathematics - Source: https://twitter.com/Mark_Baker/status/1478131480383606787 Marco's response to the person who maintains the literal largest complex mathematics library in the entire language was: > Yeah, so use matlab? This is what I'm struggling with. I am seeing a lot of things here that sound an awful lot like "that's not *my* use case, so no". That isn't how you design the language. Nikita's objection to the syntax is much easier for me to understand, because it is based on *language design*. Mathematics isn't something that is never used or never needed in PHP. The idea that I need to justify this statement is somewhat alarming. I have provided not only a multitude of examples of use cases in the RFC, but I have repeatedly done so on this list as well. I have provided examples in mathematics and examples in other domains, such as with Collections, with userland scalar objects. I've mentioned possible future scope to expand further into things like better support for query builders. I do not believe the reason people vote no for this RFC is because they haven't been shown any use cases. The use cases are self-apparent and have *also* been provided, both within the current PHP ecosystem and outside of it. Both with existing extensions and userland libraries. I sincerely hope that the reason someone votes no on this RFC isn't because they think use cases don't exist or because the use cases are fringe. I also hope that it's not because of "abuse", as this is a boogeyman that is not supported by the ecosystems of nearly all languages with this feature. The problem is that without those two objections, I'm left with few reasons I could see to vote no, perhaps the most prominent being the one Nikita raised with finding the syntax objectionable. The syntax offers a lot for future scope in my opinion, some of it not even related to operator overloads. It provides us a better way forward for allowing objects to control casting, for instance. Many find the __toString() implementation to be lacking. Controlled casting in C++ for example however is accomplished with something like `operator (int): int`. Another suggestion that came through from the community after voting opened was to use something like `symmetric operator` to show that an operator can be in either position. It also could provide us with some way forward on improving/deprecating ArrayAccess. Burden on static analysis tools perhaps? But there are features that are difficult on static analysis that have been accepted. (Enums comes to mind.) If anyone is voting no truly because they are concerned that there aren't use cases to justify it, I'd like to hear that and what sort of examples they are looking for, because I feel I have done this multiple times on this list at this point. Jordan --00000000000050bc0b05d4b8515d--