Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116649 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 32113 invoked from network); 15 Dec 2021 14:01:40 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Dec 2021 14:01:40 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9EBEF180087 for ; Wed, 15 Dec 2021 07:03:53 -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=-0.8 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, 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-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 ; Wed, 15 Dec 2021 07:03:50 -0800 (PST) Received: by mail-ed1-f51.google.com with SMTP id e3so76781836edu.4 for ; Wed, 15 Dec 2021 07:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=lq7Tr8nuSNmikgXRBjjHSoIwZYoa8rO+zRxE0elbqQA=; b=EN2iEd4DqLRyEeBsZ9z9/sQq72D0kkzI6JEgKF6U2A+6Ze1hHCJl2W3YBCKjrstB/U t2qJKwzoAzspsy6Rhk5vIgtEuz966LXenr26TSgPQrvjnEV1tiuAqNd4nOfOCVPc6DEL Z7ltPEKYvd+sJUWpiuiT2zf7Si5mB2so5A5/fuYb5xve5CGXwMesYfhUvjVAxUrD5DLa jSlqZYu8vOBDxfk4CJQlWf0h8wGyEcahMtiZLVfiy1aHPnkAIx5wctlUL+XhGkEiHn+j 7TOCEAKVSeOIS6oBOsaVV3ZV+FW9Wg+nTjdRjPq7a2p5q+KWqggvSJUmUaG80ww9UntM rsKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=lq7Tr8nuSNmikgXRBjjHSoIwZYoa8rO+zRxE0elbqQA=; b=bKAy411afiAvhDQMuV9eLO/bwq5hiaEhzKCvoOS83XjhtVKW/GsoWCGGfPktU041ac rSbmBHKawLwPk9gsMz54y3mOPMao3SZSfTAqUokB+ATBRUku820wxWuoRMEjOXxaR6xl 4+BxvKeLGfW2f2hDXvzv6KtBM2u4BKdq8XxK59DYZHmmK2pmRDd2z8Dv1pD0Q4wDc/PF FzYEdYXG6ry4OvZzGCF7x0A2QLrSU+JTv9N+Te86oCOv2dRxLrnf7yGxPu286jKQZEhP JbWpEMujsq/54RnTy4V7zbl/nQdzallHtYSuD97UhscJaxnuv0NJfOLnGTQ7T8/9ml/D a4BA== X-Gm-Message-State: AOAM533zpTd8T8F19ao5eyLpJwmrzouIRLEK9TS/4ahgPCyQQZsEuNlD rMaz1jcJUnNy3pPmS2y6q74yJfNAVG8= X-Google-Smtp-Source: ABdhPJzRTuKvDSmTnUdhQGqHFU5zWcUhRZDTd8n0sco+wcwDkHgAk5Nr8pXd/Dpq5d61hbJ5LRH1Ig== X-Received: by 2002:a17:907:764f:: with SMTP id kj15mr10757191ejc.638.1639580623423; Wed, 15 Dec 2021 07:03:43 -0800 (PST) Received: from ?IPV6:2001:983:6fc5:1:6548:ff1a:363c:c15d? ([2001:983:6fc5:1:6548:ff1a:363c:c15d]) by smtp.gmail.com with ESMTPSA id mp9sm804765ejc.106.2021.12.15.07.03.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Dec 2021 07:03:42 -0800 (PST) Message-ID: <44b3fb4b-4693-1639-c8c0-5e17296c196e@gmail.com> Date: Wed, 15 Dec 2021 16:03:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6) From: dik.takken@gmail.com (Dik Takken) On 09-12-2021 21:11, Jordan LeDoux wrote: > Hello internals, > > I last brought this RFC up for discussion in August, and there was > certainly interesting discussion. Since then there have been many > improvements, and I'd like to re-open discussion on this RFC. I mentioned > in the first email to the list that I was planning on taking a while before > approaching a vote, however the RFC is much closer to vote-ready now, and > I'd like to open discussion with that in mind. > > RFC Link: https://wiki.php.net/rfc/user_defined_operator_overloads > Hi Jordan, Thanks a lot for your work on this RFC! I like the direction this is going. One thing that may be worthwhile looking into is the query builder use case. I mentioned it before: https://externals.io/message/115648#115771 Basically it would enable using plain PHP expressions in stead of strings. So in stead of $query->where('product.price < ?1')->setParameter(1, 100); one could write: $query->where(Price < 100); Here Price is a class that represents a database column which has a (static) overload of the '<' operator. The operator overload yields an object representing a database expression, which gets passed to the where() method. In general I don't like this sort of clever construct which makes one wonder what on earth is going on. The reason I do like this particular use case is that it can simplify code and enable static analysis of query expressions. Now I'm not suggesting to support this creative use of operator overloading in the current RFC. It may however be useful to consider if this use case could be supported by a future RFC in a backward compatible way. Perhaps the RFC could mention it as a possible future extension. Kind regards, Dik Takken