Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102506 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37114 invoked from network); 27 Jun 2018 22:53:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jun 2018 22:53:18 -0000 Authentication-Results: pb1.pair.com header.from=rudolf.theunissen@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rudolf.theunissen@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.173 as permitted sender) X-PHP-List-Original-Sender: rudolf.theunissen@gmail.com X-Host-Fingerprint: 209.85.217.173 mail-ua0-f173.google.com Received: from [209.85.217.173] ([209.85.217.173:38856] helo=mail-ua0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 59/54-01794-C55143B5 for ; Wed, 27 Jun 2018 18:53:17 -0400 Received: by mail-ua0-f173.google.com with SMTP id 59-v6so2328677uas.5 for ; Wed, 27 Jun 2018 15:53:16 -0700 (PDT) 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=yC84lq4O4w38q3/m/qbjh5eljj86R/TSlIk/FFwmWqk=; b=pXljMbV5ZpDnb7aFqedvKLqc27DnNq0JyPLbm4Ra2++wjPhlPULjeKlRFa0cwwMHcI NZ6bm7D6lsdHLvZ6lEz6XG/IohDbM+jB0S5Aw8vyVEHeKGxV+WM+6DnfKv44UMJCuUMN cwhKaw6Ytjc00BkEa9ibRov3OQjAcCAE6+qlSdkMqDi1Z+pNIpcIV/ZbANkDjE3V+TQ6 G2RvvVdJl4sTWS5rTCcMGfQQSurVGi+hSJM0dyj6TEqTj7IqCIM9tS8he130+h8bMYdG yc+lVA3nNgVD5OYJfAmeJqcld+gctiWw4MgRn2oQ64BjMzZI0SZrvsikMon4R3RUY9eX nT0Q== 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=yC84lq4O4w38q3/m/qbjh5eljj86R/TSlIk/FFwmWqk=; b=gePApO6wiijaWmrDMXMfHXGtkHOVQXYcj/d2MjVSqEsUJwsHgI1WCYx0FMg9EWnYtg 2p0YfynD94nNGYZgp/4XUGdE+MnQPT9kISG+2qNFHYZOh3ICEK1z2tXvZYxaKVrHxNwr ozeE8V7bhSnwdkBfAKBkTd64IJE996gcLj+MZmJw/j2XMnllPJPCGAmcc9J448jBpWG6 k7g2iMlNJqSHd3SH+zhf3Om7z3uofkgXr/DL/NYMpC+2zL4cAIJmVhTqd6UkWn5QnpeJ Bc3LEurwiQ7OwoM/mSgGBkNA5JxqZ4vBTimUyr1slf5uCsmAXadbhwb3I2cbDXVZavCJ MPHQ== X-Gm-Message-State: APt69E2I+xhQWb3K9rDJZN4PpaO3i5HedpTA/8I+6rcOVCD8BhCAhHAm kig3xK5pSlBVeXWUng4Hcz7j0c17uO4Q/y2c3ygt0lpG X-Google-Smtp-Source: AAOMgpcJrJoEV2fPZ3zhnIvAUHNETfKVcdbCN9A7cxJjyAcDNm+gaiH39LW+ZCcMCSKGA+Xz3U+D5soOrV0j3nj/gl8= X-Received: by 2002:a9f:35b1:: with SMTP id t46-v6mr4176141uad.190.1530139993571; Wed, 27 Jun 2018 15:53:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 27 Jun 2018 18:53:02 -0400 Message-ID: To: levim@php.net Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000c60715056fa77a7a" Subject: Re: [PHP-DEV] [RFC] User-defined object comparison From: rudolf.theunissen@gmail.com (Rudolf Theunissen) --000000000000c60715056fa77a7a Content-Type: text/plain; charset="UTF-8" > > In summary, I propose that return type constraints should be removed > which will allow us to pursue specific operator overloading at a later > point if we desire There are no return types or parameter types. The only requirement is that the function is public and not static. On Wed, 27 Jun 2018 at 15:21, Levi Morrison wrote: > On Wed, Jun 27, 2018 at 12:24 PM Levi Morrison wrote: > > > > On Tue, Jun 26, 2018 at 5:50 PM Rudolf Theunissen > > wrote: > > > > > > Hi everyone, > > > > > > This is an RFC that is based on previous discussions here: > > > https://externals.io/message/102337 > > > > > > RFC: https://wiki.php.net/rfc/object-comparison > > > > > > The implementation is tested and appears to be working as expected. :) > > > > I had some off-list contact with Rudi and generally have agreed with > > these changes. > > > > However, there may be some value in following Python's lead. In Python > > 2 they had a `__cmp__` magic method and in Python 3 they removed it > > and added all of these: > > > > __lt__ > > __le__ > > __eq__ > > __ne__ > > __gt__ > > __ge__ > > > > This permits things such as NumPy to overload < to do an element-wise > > comparison of the members; something like this: > > > > np.array([1, 3, 5, 7]) < np.array([2, 1, 6, 6]) > > // evaluates to np.array([true, false, true, false) > > > > If we pursue this Pythonic route then we would also need methods for + > > - * / % etc. I do not want to derail the conversation too much, but it > > does seem opportune to discuss operator overloading more generally. > > We would still need `__compareTo` if we did operator overloading > because we have the `<=>` operator. Rudi has pointed out that because > of this we should be able to overload individual operators at a later > point without backwards compatibility issues if we so choose. I think > this is true if we do not constrain the return types. > > In summary, I propose that return type constraints should be removed > which will allow us to pursue specific operator overloading at a later > point if we desire; an author can always add `: bool` or `: int` to > their own methods if they so desire. > --000000000000c60715056fa77a7a--