Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115652 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 63153 invoked from network); 7 Aug 2021 13:59:33 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Aug 2021 13:59:33 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CF7311804AA for ; Sat, 7 Aug 2021 07:29:18 -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_H2,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 ; Sat, 7 Aug 2021 07:29:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1DA7A320092F for ; Sat, 7 Aug 2021 10:29:17 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Sat, 07 Aug 2021 10:29:17 -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=2lJqit dwEe/Cnn9rUmx2PYNwdk9hKiDc2+WfMf04iDo=; b=sKNn8I7A2FkNPHMDiAr+9o 0jhDVnWwXqA19wQjUvc7GgJAtuqSOnPxlJAa7MVHmcldph/tTeeTb6r3Gg3hnEqk dijwhY2BcXt3VAfdG0Qwx0us2lVf4s3yu+Dhr9qHDMoNY0KWVuPZyaeSu+rycQZ/ yzX81rsd5GkTjSmSwUntGN6r19cp0IHmv++bRJjAELIIFjAq2wZLbuAPp59EqNdj 5j/6OOmGNy2vv/TA8LdGtAdevYbb80jp82t2pNUo0TVZ4KfqPM8WUvzK7tE5mAg0 Q+oh5yBPwCQB10C1lrXD3ODtTCmMTC3nV+zb2nqub5lx6RbkW2sw/byD7PTh7MWw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeefgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuggftrfgrthhtvghrnhepgeelgfekudeivddvteffueejffdthfejieevhefgffek udevkedtvdelvddvffefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 712E1AC0DD0; Sat, 7 Aug 2021 10:29:16 -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: <50a33114-cca4-4f34-849e-5d49071444fb@www.fastmail.com> In-Reply-To: References: Date: Sat, 07 Aug 2021 09:28:54 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads From: larry@garfieldtech.com ("Larry Garfield") On Fri, Aug 6, 2021, at 3:18 PM, Scott Arciszewski wrote: > My recommendation is to have a base interface for every operator that can > be overloaded, so that these can be composed together. > > AddOverloadInterface { __overloadAdd(): self; } > SubOverloadInterface { __overloadSub(): self; } > MulOverloadInterface { __overloadMul(): self; } > DivOverloadInterface { __overloadDiv(): self; } > ModOverloadInterface { __overloadMod(): self; } > LeftShiftOverloadInterface { __overloadLeftShift(): self; } > RightShiftOverloadInterface { __overloadRightShift(): self; } > XorOverloadInterface { __overloadXor(): self; } > etc. > > Then if you were implementing matrix math, you could do this: > > MatrixMath implements AddOverloadInterface, SubOverloadInterface, > MulOverloadInterface { > > } That would be roughly how Stringable/__toString works now. I'd be OK with that, if it's going to be a language trend. > This prevents you from having to define methods for operations you don't > support. > > It's probably worth exploring whether common combinations are worth > defining for convenience. Now that intersection types are a thing, I don't think combo interfaces are worth much here. If anything, it would be just more impetus for type aliases to reduce typing. (Human typing, I mean, not code typing.) --Larry Garfield