Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116796 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 43913 invoked from network); 3 Jan 2022 22:20:40 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Jan 2022 22:20:40 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3835F1804F8 for ; Mon, 3 Jan 2022 15:27:43 -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-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) (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 15:27:42 -0800 (PST) Received: by mail-vk1-f177.google.com with SMTP id s144so19745383vkb.8 for ; Mon, 03 Jan 2022 15:27:42 -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; bh=FF5xNP445NFxLPamJ7E6PZB2+4xsaJZXcwhuDkPMkRI=; b=3KbooXNGRn555wuiBTFVR54HMIYsfLxGuOfnNVJN4IadyOYMjfSNZAfkEPxXoDLmRW s21p0TKI99+LzK++r80QJZZ92dg7t6VqrS0OxdVX496YvElYMe3gzwsPX/YLdGoqDZeB fX5eBKWgRehls3jXaY3nniLgzFw21HFkXcOSMomWJnwiWLX1GQJE2TutTOvwKf/c44M5 ktyyEVwsKhJjYTDo4Ng2zcYnudhYViafDLvhKKiF2rwA8ZR9TSRdk9hHrr4oVNadAa/G YLAiNx89+H4oS3s2BbWzjBMX9W6Zfojy+vLW4gLiUSFKoKdlxHOuzKxvweWWjf2tY61A xtiA== 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=FF5xNP445NFxLPamJ7E6PZB2+4xsaJZXcwhuDkPMkRI=; b=6hi20peoz+jU+s2tLhEDhR1FPxdGjPz5kf1Vv5BG1F0XB7eI/sOmNzI1+tyP97goOI gV4ZXPAseKshLybKOfY8cawIM9a6UxAQ2VrvhzYG4ddYLdBqDWPF+0aOAWeEIdPaX4yO 6BmrJHuppSf8PFDbjR30eicxcGPyURnSTRFuRcsFkohtfYfCaJBx2Fnx+qhiFZdBZCOV TVQMqCvApWbm6utuCa9Q27XUEnONJKPouy9I8YY/EoYX66FQVmwHhrfSnoCRtOesQy8u E2XsB3q0hrke61EdhePrmpV/CGcBqxa0AQySvaB2xfIeGBwfqLAaa3YZdrtNK9eiWkW+ xGHw== X-Gm-Message-State: AOAM533w+KM+byaVdvbVwBZhKqt3Ln3CkYUrfVru4Gy4AgVg898b2xh/ /9iaNM02sWvydMCgGDHJ1NDeiGM1QSxUmmyyrm5B/dcxVr3Eib/f X-Google-Smtp-Source: ABdhPJwqzFaGH7ME4limeKYnngBZZqEPGLyMCRFG/FgaLMkORyoqXrxHoWPBlfifYFq+LbCNLHFrXeTYTkPwTbOxLSE= X-Received: by 2002:a05:6122:b64:: with SMTP id h4mr15999707vkf.24.1641252461796; Mon, 03 Jan 2022 15:27:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 4 Jan 2022 00:27:30 +0100 Message-ID: To: Jordan LeDoux Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [VOTE] User Defined Operator Overloads From: andreas@dqxtech.net (Andreas Hennings) Hello Jordan, I have another note about the RFC. (I am not sure what's the policy, if we should continue _all_ discussion here or go back to the RFC thread. Hope it's ok here.) OperandPosition::LeftSide OperandPosition::RightSide I wonder if this is the best way to model this. Especially, it does not account for the case where an operator only works in one direction, or the allowed operand type is dependent on the direction. E.g., (Money / float) is ok, but (float / Money) probably not supported. Or if it is supported, then the return type will be quite different. You can throw an exception, but this is not useful for static analysis. An alternative syntax with a few more keywords: abstract class Money { symmetric operator * (float|int $other): Money; // Commutative. left operator / (float|int $other): Money; // Only $a / $b allowed, $b / $a not possible. left operator - (Money $other): Money; // $a - $b right operator - (Money $other): Money; // $b - $a } Btw, in the Matrix example from the RFC, under "When will $operandPos be useful?", the $operandPos is not really useful, because it will always pick the default $a - $b version. The same applies to "-" operator in my Money example, because $other already implements the operator. The $operandPos is only needed if the left operand does _not_ implement the operator. Which is the case e.g. for complex numbers, or the Number class from the RFC example. I am trying to think of cases where ($a $b) would have a different type than ($b $a), but I can't think of any. Or rather, for any case that I could think of, the mirror operator could simply be provided by $b. I am not married to the modifier names, e.g. it could be "symmetric" or "commutative" or something else. For left/right perhaps I prefer to talk about the "default direction" vs the "flipped direction", not sure how this could be turned into keywords. If we don't like more keywords, perhaps something like "!operator" for the flipped version? Cheers Andreas On Mon, 3 Jan 2022 at 01:14, Jordan LeDoux wrote: > > Hello internals, > > I've opened voting on > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will > close on 2022-01-17. > > To review past discussions on this RFC and the feature in general, please > refer to: > > - https://externals.io/message/116611 | Current RFC discussion > - https://externals.io/message/115764 | Initial RFC discussion > - https://externals.io/message/115648 | Pre-RFC discussion and fact-finding > > Jordan