Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117706 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 68386 invoked from network); 9 May 2022 19:46:51 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 May 2022 19:46:51 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 506F2180211 for ; Mon, 9 May 2022 14:25:26 -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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29838 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (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, 9 May 2022 14:25:25 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 760ED3200C79 for ; Mon, 9 May 2022 17:25:24 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Mon, 09 May 2022 17:25:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1652131522; x= 1652217922; bh=6SlfAyLDmgv8iNc/u75KeY3Yh69EYvutQ1Q53l0veig=; b=c jtsGjt8fVxlxAQ0mENN8pBAdql/E5LMWi57i2UO+RKQTYN/vIsTUQOWP5m8SkjXo jUTDhlDo8bVfI6mHvTusoHG8+SuPfcgOSrVQEk22FmsUAMvKrwahWLdMJth7bpOv F4g0K9P7e/Gb5BXlznYLHjd4ifyVoKEFdOgvz7iQBcDLmbsCoqmSnVmXtii4SyNn KQ/a1AL+hMIljvQNcWPKd5Lw0RPCZoQ6IsU4O5wMgdhhbifsuYZ/i8ZdLvtvYEfv kdF3fh0k+hdynGFfWG/UHsC98l0OeWDW/1Y+YmKgs++2Di5HFdIMtIYGRHN1hg1P I33yCeruhkqxbfA2cZjRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1652131522; x= 1652217922; bh=6SlfAyLDmgv8iNc/u75KeY3Yh69EYvutQ1Q53l0veig=; b=G bUeDUzN0YRcdArJeToKmUVnwMauSUUnD43nNDJSdtJYJe45gmmXhghjB6+RyMb9O a3rvuTrsgp2YN3/3PWPwqeYLwUqLBDLclLfk6GyNqxT8zwyXYoWsqohLDlZb26en +wNiCz7p9GsUQ4aQgCUbx+nVsalLKpZn3rGHdEVWJCny8tJSg5GRwzWzqJWHvLpN fNheH2Iw2O/oDxWpA2bO7nZHwCR02xJXYOWy5pcW+phWw6ZVKuTEdFDbBMC8DEKl 69IxOnRk1OTyOC92uBEoYWfgP0MdazLsUAA2MitY+J5RjI2g6Ff3vMINkFQ2+h0P /y4vJJUmNY7M08koOBM1g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeelgdduiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeeglefgkeduiedvvdetffeujefftdfhjeeiveehgfff keduveektddvledvvdfffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AA2A72D4005D; Mon, 9 May 2022 17:25:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 Mime-Version: 1.0 Message-ID: <79a5c3a9-5f4d-4226-b640-1e619a43f99d@www.fastmail.com> In-Reply-To: References: <71cf150f-974a-4944-a1a4-42618c160948@www.fastmail.com> Date: Mon, 09 May 2022 16:25:02 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] The future of objects and operators From: larry@garfieldtech.com ("Larry Garfield") On Sat, May 7, 2022, at 3:59 PM, Jordan LeDoux wrote: > 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. It's possible. However, it wouldn't be the first feature that has laid dormant for several years until the voting population turned over. (Scalar types and attributes are the first such examples that come to mind, but I'm sure there's others.) Also, not proposing level 1 on the grounds that it would reduce the argument for level 2/3 in the future would effectively be holding level 1 functionality "hostage" for the more advanced versions, which... would probably not work out well. :-) (Even if that's not your intent, it would come off that way.) Conversely, giving people a version or three to work with level 1 operator overloads may get more people comfortable with the concept and thus make them more amenable to levels 2 or 3 in the future. Whether there's enough support for level 1 for it to pass at the moment, I honestly don't know. > 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 I defer to you and others on the technical implementation, as it's well outside my wheelhouse. --Larry Garfield