Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108341 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76494 invoked from network); 1 Feb 2020 11:11:06 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Feb 2020 11:11:06 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 900791804E6 for ; Sat, 1 Feb 2020 01:22:26 -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=-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 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-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (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, 1 Feb 2020 01:22:25 -0800 (PST) Received: by mail-lj1-f169.google.com with SMTP id f25so9586550ljg.12 for ; Sat, 01 Feb 2020 01:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yrFHr52B7luUJ04AyDF5zJ7fNVNi+65jy36QVPXQ5gk=; b=csWT38bE+4p1plkEYV9ZKsVarYvozUyL3l+0HqVTQhTgXTKxQCZOYB0ScaT4KQtT3+ 2ddbqibA5WSQy+ILAXN+ELgAK14pfTc9lNcbBJSbOlRoA/oVQ5up9LRvk1sceYHyCT8I 6QM3nqCdDSPwik97Nse/Zmzxj3iVeKvP+NCv0zWADwvASmc93HocvB6YZZrdbUM0EBkM r/rJ/XZP8D9/8IGDsFclMl/OT/8HPTOfNsbZa2B2c0hunFWNb+uLSzFeshMuHUY8E4Tp FEOt1Pe+N83uv9rSIDOhKWnvcUbiSPspK4C7MEWR29iBfMfQnyoFNTSWBoCB6xqAkKVs 5/rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yrFHr52B7luUJ04AyDF5zJ7fNVNi+65jy36QVPXQ5gk=; b=ZgeUqhryNydW5XpkcyCUZjVW5MfL/wpN8FTPODEj4e7sthbl9P81/W4vEYJ3rgVJnC ybWNR9VWkHKS2TuaaydQnFUy/pqXqaJj3D1GGrhFnmEXFBJ4UORmx52utUXC0/4eMa2b nbe/GLSYvKi/cjdJFNGVWK5q/IS8PmGwTMIpYvbU4IxreSzXmN6WJu/l4rkuY6gIqhM/ nfnk0IUnBFLnKRWhfyjBV01F2LQwCNEw9hrhYSRwK+BxDFEpbwb43tTiQlcFnusJdqfx 4KHEjYj4nfKJFBca5fFaFHEoWtudhqAmy7M6bs7Xsdf7U5eMj90S3vEU9z+afdyWfCW+ 1HqQ== X-Gm-Message-State: APjAAAWSkbsuB01cduz9As+UBFUVx0EXPJtVH7Z/wW82BTOMTLimJu7m LrXzsL0KhBGRZzGpWCPv5tXuyYJwDv9DIf2bBjs= X-Google-Smtp-Source: APXvYqz7FhKPOSwBuIBDmwuyVMINa/rGAd37gc69uHDgItnfGeutUoxcxEdKr1+jGz3Ikvw48VKgc1xyP/vqF+cEPy4= X-Received: by 2002:a05:651c:297:: with SMTP id b23mr4050773ljo.260.1580548944309; Sat, 01 Feb 2020 01:22:24 -0800 (PST) MIME-Version: 1.0 References: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de> <001f01d5d7b3$68c18b10$3a44a130$@gmx.de> In-Reply-To: <001f01d5d7b3$68c18b10$3a44a130$@gmx.de> Date: Sat, 1 Feb 2020 10:22:08 +0100 Message-ID: To: jan.h.boehmer@gmx.de Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000603187059d803a71" Subject: Re: [PHP-DEV] Operator overloading for userspace objects From: nikita.ppv@gmail.com (Nikita Popov) --000000000000603187059d803a71 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 30, 2020 at 10:22 PM wrote: > > Unfortunately, this implementation goes in the wrong direction: PHP > already has full internal support for operator overloading through the > do_operation object handler. Operator overloading should be exposed to > userland through that handler as well. > > I have made another implementation ( > https://github.com/jbtronics/php-src/tree/operator_overloading) which > provides an standard handler for do_operation, which calls the functions in > user space. > Looks much better! If you submit a pull request, I can leave some more detailed comments. > I also removed the __compare magic function from my implementation, so > this can be handled separately. > > Another thing: What are your opinions on overload the bitwise not operator > (~)? My implementations offers every other bitwise operator and this one > would complete the set of bitwise operators. On the other hand unary > operators does not have much use for objects and maybe encourage people > using them as "shortcut" for calling things on the object, where an > explicit method call would make the intend function more clear. > Don't really see a reason not to support it. We do overload the bitwise not operator for GMP objects, and it would be equally applicable to other "integer" style objects. If you would like to start an RFC on this topic, please sign up for a wiki account (https://wiki.php.net/rfc/howto) and send me your username. Nikita --000000000000603187059d803a71--