Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117691 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 99595 invoked from network); 7 May 2022 19:21:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 May 2022 19:21:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2401218005B for ; Sat, 7 May 2022 13:59:12 -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=-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, T_SCC_BODY_TEXT_LINE 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-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (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 ; Sat, 7 May 2022 13:59:11 -0700 (PDT) Received: by mail-yb1-f182.google.com with SMTP id v59so18466035ybi.12 for ; Sat, 07 May 2022 13:59:11 -0700 (PDT) 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=YfttPtMelzvk0PgInARc/uC+tMXQP24/RX0TCWVnII0=; b=JnWNJkPVRzngIIZ+Ww3aB8TQPVhovWJ8o0G1tjMaHEjIkQfpTa/lpZHhUN9ybA20LI s1wommCsGnaXV9YjwWt+0VIBIEBnD06IY2vL2wehKqdWntoXUUW9O0fW0GDihuDEYsrW Rp/CuYOtigM2lf26kVgeqqy5BEmcqg+9vQ+yNUi77dywzZqm58S6i6iSxU9cUMfA+bOI 6+InuwI5XZLW9DLk9o6ocYB+oDJ8RTIi4FuuKOihtULKNQ+y8221OwO/8F16KEbannBn JRzYXtrDwBCdgvE+kX6NOAmg7FoAOTWtooUG/kPvKmtBWUfW9Tekzu2jJhjZdKti+tNP NAAw== 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=YfttPtMelzvk0PgInARc/uC+tMXQP24/RX0TCWVnII0=; b=vDGO2M93qBe0JtPnTDkgQRfFRfkUhgKoVDVYEjj77w/jXJyTL5/QN9S5+6DCpTbZNM osS57LXIC80SIdVM2V5aVKzKljp8Di90bjh3EG6B6iX8b8ylsBuFmVY2sC3NOpJkyxW0 RjwYji5MTvfVadJqQZH7Q+9iAWW04HdAPkDdxVjo+AV7Z8lCevDtMGJ0b9JxsWlR44QM kwk9nf+n7sMFH0GT/XTJsrUAQ/wxemL2vejYTeP9+BmVla3ZrZE8UTamRb8TCnqe1kmm UjLWGGmlv5T5rVq4sgIDxzl6jGUSLBy60TacZLt77MxeE0z4lzinhfaIsg0algnP5nSH o+Og== X-Gm-Message-State: AOAM533Q9aVZTixKz9NbN30SG5VcjOD164PlK9yIcTI+sod9LuWJdAdE Zi0c4IRFzr3zk62hs+zrsWFMYcF1wV1O9pQqX8tVWML0 X-Google-Smtp-Source: ABdhPJzwLAu0S4sT0d6R3Dm3hLxf5OZM6rs1VldMIJKssLKfKVCSpPqCfPKvsxOMZNaADbUSVIJNg8w6WxbfYguTZ0E= X-Received: by 2002:a05:6902:110e:b0:644:daff:1e6f with SMTP id o14-20020a056902110e00b00644daff1e6fmr8058312ybu.569.1651957151019; Sat, 07 May 2022 13:59:11 -0700 (PDT) MIME-Version: 1.0 References: <71cf150f-974a-4944-a1a4-42618c160948@www.fastmail.com> In-Reply-To: <71cf150f-974a-4944-a1a4-42618c160948@www.fastmail.com> Date: Sat, 7 May 2022 13:59:01 -0700 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000002bb72505de723f6b" Subject: Re: [PHP-DEV] The future of objects and operators From: jordan.ledoux@gmail.com (Jordan LeDoux) --0000000000002bb72505de723f6b Content-Type: text/plain; charset="UTF-8" On Sat, May 7, 2022 at 11:40 AM Larry Garfield wrote: > > I would group object operators into 4 categories/levels. > > 1. Object-universal operators. This would be support for operators that > make sense in all domains. Mainly this is the comparison operators but > there may be others. > 2. Arithmetic operators. The 4 basic operations. Maybe even just 3 > (excluding division as it's a bit more complex than the others > conceptually). > 3. Full operator overloading: If an operator exists, a class can override > it, on principle, even if there's no obvious common use case. > 4. Custom overloading: User-space can define additional operators for > specific objects. > > Jordan's RFC was effectively level 3, with a syntax designed to be > extensible to level 4 in the future if desired. Naturally the line between > these levels if a little bit fuzzy and there's some overlap. > ... I frankly think this is a red herring; it's a "I don't do heavy math work > in PHP, so arguing that feature X makes PHP better for math carries no > weight." It shouldn't be read as "PHP being good at complex computations > is bad in itself." (If anyone does actually believe that, I'd say speak up > but I'd just tell you that you're wrong from the get-go, so maybe let's not > pick that fight and leave it as a hypothetical. :-) ) > ... > My recommendation would be to use the same syntax and model as before and > just target object-universal operators, ie, comparisons. (Level 1 from > above.) That gets the syntax in place, and lets us flush out the engine > hook weirdness. If we could get that to pass, it would at least get people > comfortable with the idea and concept. The higher level parts could then > be an easier sell in the future in a version or two once people have gotten > more used to the idea. > > Of the people who did vote no and also provided me feedback, there were *mainly* three reasons given (some in public such as on this list, and some in private in more direct conversation): 1. Math is not a valid use case. 2. Operator overloading for objects is something I will vote against in any context for any design, no matter the argument or evidence provided. 3. Operator overloading presents problems for static analysis and tooling which are more significant than the benefits. I could argue against all three positions, but as you noted, I don't think argument or debate is really helpful right now. Instead I'd like to talk at a more high level about what sort of long-term future PHP contributors and voters see for objects when it comes to allowing developers to control object behavior. I like the way you organized the different levels of support within the feature, it's a good organizational structure for thinking about the feature-set. Given the feedback though, I found myself a little concerned that if I created a Level 1 proposal, it's very possible that the people in groups 1 and 3 above might vote for it. However, in doing so it's also very possible that all the use-cases those voters care about would then be covered, and many would then block anything which helps use-cases they do not commonly use. In essence, the particular feedback I received made me concerned that passing a Level 1 RFC would basically guarantee that Level 2+ would never happen until the voter base itself was significantly changed. Even so... I think I agree with your suggestion at this point. At the very least, even if my concern above was proven true, it would then at least be *possible* for me to provide an extension for PHP which addresses some of the shortcomings for math. The main issue when it comes to comparisons is addressed in the PR I linked, which basically boils down to "for objects, it makes sense for equatable and comparable to be separated sometimes". Whether this involves a fall-through in the VM for objects as done in my linked PR, or involves new handlers for objects as CMB commented on that PR instead, it's actually a very minor change technically within the engine to implement Level 1 support as you described it. Jordan --0000000000002bb72505de723f6b--