Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115686 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 36641 invoked from network); 10 Aug 2021 13:52:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Aug 2021 13:52:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 84F8F1804AA for ; Tue, 10 Aug 2021 07:23:20 -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.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 66.111.0.0/20 X-Spam-Virus: No X-Envelope-From: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 ; Tue, 10 Aug 2021 07:23:19 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 48B785C01C1 for ; Tue, 10 Aug 2021 10:23:19 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Tue, 10 Aug 2021 10:23:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=L1zhy+ 5fSkXh14bZ/Sz3LzpkjhKhXk142K/CF8UJ6JY=; b=iw8Ti5qP4yImV13r1rhVsZ k4Gq8RbgXjKGJBc7ZYPzReS7LHcppexs9zVcP49ByLNq/kHaonI0Q+Z3wCIhaYjl b4SwqMYimYyufZ9YYSL1ok1QBiXgjB/TDSRV3y2coj+qWR54HOC7zIPSq3x83tT6 ISZ9MEFLwu9/XEMw0Bvho84W3lDwOC3/cEqpu9UJpTLPJ2PXQUkQ7mxF+RDTXAXL PEX7RWjTltsXDF3Zc28eezswG0k/IFwYiYhCECLoIgc5+Fj2kQ+ZFkjoMBTL5oYL f0MwMM8UcWWu0IPmxydBDjiIJuJPqfez+UfXPXtB1g6Ok4Rr2yaoWC1w6s5bge6g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeelgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuggftrfgrthhtvghrnhepvedvjeevuedvgfeluefhfefghedvieeghfegkeffudek udffgeegledvueefudevnecuffhomhgrihhnpehtfihithhtvghrrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgrrhhrhiesghgr rhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 939D8AC0DD0; Tue, 10 Aug 2021 10:23:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-552-g2afffd2709-fm-20210805.001-g2afffd27 Mime-Version: 1.0 Message-ID: In-Reply-To: References: <94696d46-c4e6-406a-b859-89144bff31bf@www.fastmail.com> Date: Tue, 10 Aug 2021 09:22:58 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads From: larry@garfieldtech.com ("Larry Garfield") On Tue, Aug 10, 2021, at 1:51 AM, Mike Schinkel wrote: > 2.) Then I thought: What if PHP had the ability to explicitly define > *value* objects? I know this has been something Larry Garfield has > mentioned[1] in the past. > > What if we had a new type of class that is to be used only for value > objects. Following Larry's lead they would be immutable. And if we had > those then I think adding generic operators overloading to value > objects would make a hell of a lot of sense. Maybe: > > #[\PHP\Value] > class ComplexNumber{} > > Or: > > class ComplexNumber value{} > > Or: > > ??? > > Can you see any reason why only allowing the addition of operator > overloads to *value* objects would too limiting? > > IMO that would minimize the abuse potential for implementing operators > as a leaky abstraction when developers are ignorant of the > ramifications and/or are more concerning about their convenience than > longer term maintainability. > > [1] https://twitter.com/Crell/status/621715583403487232 Point of order: I do not support a dedicated value-object/data-object construct, and have said so explicitly. I support targeted tools that make using objects in that fashion cleaner and more robust. (readonly, asymmetric visibility, clone-with, etc.) Please do not misrepresent my position, especially when I've been fairly consistent on it. Also, one of the biggest failings of SPL is the degree to which it leverages and forces extension rather than interfaces. Inheritance is a code reuse tool, NOT an architecture tool. That's what interfaces are for. We know this. We've been bitten by this. Building any kind of inheritance-based operator overloading into the language would be a terrible idea. Let us never speak of it again. --Larry Garfield