Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116820 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 82845 invoked from network); 5 Jan 2022 19:16:52 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Jan 2022 19:16:52 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9D0AA1804A8 for ; Wed, 5 Jan 2022 12:24:24 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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, 5 Jan 2022 12:24:24 -0800 (PST) Received: by mail-ua1-f45.google.com with SMTP id r15so594385uao.3 for ; Wed, 05 Jan 2022 12:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dqxtech-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6Np+0oxW0cp3tp9YfiooTlslXUA+hx+Kpp3+0vf+vv0=; b=uacPdY2mICT2AXYZXYe1x0oJ0aYdbZQPYTmG3oSVT07PlBMKeU2Kr+7RmP9CtMxyUP c4dcoJPCWX5a9zrtnDwKlTBYkMBOHIcfeCyi9a+Oj/XfifC0si+R689PYGRcGSL8M0kg l6GGn0QeXJ2P3YEuk06GJb1AEDK+iGw64egHUbucRPjBn8k/uIBNOG9Sw202vlOxNR5W n3b1HZlBdSZ6FIKf2dKnakuMjPZMDNUfImUx6ORS7wxV79jsySPNb8SUKyBK8nIrD8FL DwsTdFVMa58UhZopXSQv1SxWyUP4EE7d+OSw3loX4AS2MezTE64xV7FhiVkK0CHU6o1k lGLA== 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:content-transfer-encoding; bh=6Np+0oxW0cp3tp9YfiooTlslXUA+hx+Kpp3+0vf+vv0=; b=bwsPBQuYRpPATQ1YFCfR85rXIZkiwFt9hMMnhDadzLfD8SM/i7kzY+D5O83j4q537j o/rUpT2fhdpxzB8Q6s35ZTIprYTpZkDeN/dQzohwb7R3iOwz6pY9HJ7Wu8gE5qu/Ubvv 4e5WTUQgpRUw3pfXwQS+PTJiL30B7bNLdX58k9X6sWqr+QZYJkwZtQuRr8jdktNV+BYz OgJ3Pbpbykz3uLpRUob3UONY/DbHN/ZlsKFWMkzx8eKPQf7gqsWbdJLYHQoDs5M084eh SdyGKaNbqaR4B1YmFebOv8k3OPRmZzwQcij5COZ8Lb7MURVqBrKKD9XN2bObkHqP5QWp wRMw== X-Gm-Message-State: AOAM5315VIUxjT8F6ILCBXTtvoUqFFyXyyz6Fo3Mog9BqVUVVpumOeJ5 7JrtDkQcmvU9Aw5j27IDUjpbbuPzGVqYz2G+TCH7XGMNgn7AJg== X-Google-Smtp-Source: ABdhPJxdhQvBGXVlLpC80h+cfPLATlOzHF1tiNEyxjvG2AhGi0kXSgwXBHBUkzJ7io6pDoayol8b08aLfzFAgQVWo5w= X-Received: by 2002:a05:6102:736:: with SMTP id u22mr17884591vsg.60.1641414263186; Wed, 05 Jan 2022 12:24:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 5 Jan 2022 21:24:12 +0100 Message-ID: To: Jordan LeDoux Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads From: andreas@dqxtech.net (Andreas Hennings) On Wed, 5 Jan 2022 at 20:11, Jordan LeDoux wrote: > > > > On Wed, Jan 5, 2022 at 6:33 AM Andreas Hennings wro= te: >> >> Hello Jordan, >> do you have any thoughts about these symmetric/left/right modifiers, >> to get rid of the $operandPos parameter? >> >> To me, the parameter could be the kind of thing where in hindsight we >> ask "why?". >> >> Also, can we drop the "public" modifier, if we do a new version of the R= FC? >> >> Cheers >> Andreas > > > It's a totally different design concept (symmetric/left/right) and I've b= een going over the design implications before I responded. For instance, wo= uldn't this be a special case of method overloading? You're overloading acc= ording to a modifier, not the typing, but there is that to contend with. If= someone defined `symmetric operator +` and `left operator +` which would b= e used? (My feeling is left as its more specific.) You would not be allowed to provide both on the same class. A class can provide either no operator, or the left operator, or the right operator, or both. A "symmetric" operator is a shortcut to providing both left and right, but using the same implementation. A class with a "symmetric" operator cannot also have a "left" or "right" version of the same operator - this would be the same as two methods with the same name. However, if the parent class has a "symmetric" operator, you _can_ override the "left" and/or "right" version in the subclass. In that case, if the subclass provides "left", then the parent "symmetric" implementation would only be used for the "right" direction. I am writing "right" and "left" here, but perhaps "normal" and "inverted" would be less ambiguous. Also, perhaps instead of "symmetric" we could write "left right". Perhaps this code will clarify: class C { symmetric operator * (int $other) {..} # left operator * (int $other) {..} // -> Error, already defined. left operator - (int $other) {..} right operator - (int $other) {..} left operator / (float $other) {..} left operator % (D $other) {..} } class D { right operator % (C $other) {..} } (new C()) * 5; // -> symmetric operator * 5 * (new C()); // -> symmetric operator * (new C()) - 5; // -> left operator - 5 - (new C()); // -> right operator - (new C()) / 5; // -> left operator / 5 / (new C()); // -> Error, no operator provided. (new C()) % (new D()); // -> left operator % provided by C. (new D()) % (new C()); // -> Error, not supported. This means, the "right operator" will only ever be called if the left side does not provide a "left operator". Basically this is not so different from your RFC. Just instead of having to do a "if ($operandPos =3D=3D=3D OperandPosition::LeftSide) {..}" inside an implementation, we are providing two separate implementations. > How would they be stored within the zend_class_entry? Since they would te= chnically have the same name, something would need to happen for them to no= t be in the function table. The right and left version would need to be distinguished somehow internall= y. I would say "left" is the default, and "right" has a modifier to its name. Perhaps for symmetric operators, we could store two distinct entries internally, if that makes things easier. > > The public modifier is not required (as stated in the RFC), you can just = add it if you want. Are you asking for `public operator` to produce a compi= le error? That would be the idea. Perhaps others will disagree. Allowing the "public" introduces a meaningless choice that people can argue about in their code style, and have pointless git commits where they add or remove the modifier based on preference. Of course the same could be said about "public" in interface methods. -- Andreas > > Jordan