Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102523 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25456 invoked from network); 29 Jun 2018 02:48:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jun 2018 02:48:14 -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.194 as permitted sender) X-PHP-List-Original-Sender: rudolf.theunissen@gmail.com X-Host-Fingerprint: 209.85.217.194 mail-ua0-f194.google.com Received: from [209.85.217.194] ([209.85.217.194:37905] helo=mail-ua0-f194.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7D/2F-01794-BED953B5 for ; Thu, 28 Jun 2018 22:48:13 -0400 Received: by mail-ua0-f194.google.com with SMTP id 59-v6so4876646uas.5 for ; Thu, 28 Jun 2018 19:48:11 -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=hNAJ/d7LjR3SIHL1sE7xNQOqIriPmKg479ZYlvvzor0=; b=opmsKqQjaDWslOl7o1QNTEuDNmNOH7RgvQfrTxi3X8clT8hcxaT7nrY6TsdwlEhSrJ /KbBQL8gE865rIGIIUBSTdeP5jLNEKY+tH9EFH2BGEsoYJzTUJrh8RRcwSGju0xy/mTU xx9cu2IRCAESScxmOv4fDkeDe/MILaUa7DrilTOAGb+4jbdP0WXpunCCaUjPpZfRy6Y0 fEk1If5EOMKSrGiDU1FDXp1EZ057KXO0Op8sTilPRY2LXYiMGKHDjx2HjfXxVHOupy6d suFPj4loDh/q+vFFH1YpxASKLK8z3ucSfYjiaPBOCvuwC9POIBodPdeAyXN2GDCPxeZ8 YJ0Q== 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=hNAJ/d7LjR3SIHL1sE7xNQOqIriPmKg479ZYlvvzor0=; b=uINnHEqhWJv6nsv1ejBDacA+VMlJ6KaN1TwHl2VeXqlpYvYtK9AvB7AGUkb116YMrG TGWYaBNZxzp7oPh2BdJ0pvUjUoRD6vwY2kHKX2xRDCDsr5x7ikU92ggM6JIPiJi/38/N j+41wO/UqyNozKdARwW5SNeWDk3UMfoKX32UqrNn+0IM/YdUO3pAMv7voZXg7MV9poh/ bVUnPHTLgRX3F1GOcKvyuI9L4yFYqRheyAyE+38D+U8jdwIkpgKb6x1RfYtSvisdcFYQ 8k4D2ZB3+K3dMElVEPa+NWmRX9OgYKa8e/soh3a2WoJl1w2Y3ZIApYufS97pA3cUPp09 q+0g== X-Gm-Message-State: APt69E2JZAADjMk0ISIl4PlANxVFTSJ8NtRQ4pmQ0US7gTMV4YglL8Dv qhsR9YEdPzi+a7X58dG5jrkzbIU22grTgIfJJvgVAufA X-Google-Smtp-Source: AAOMgpfDqEeCmEc6fzxFvaG/3r6soZUxGdIkIrgz4VLWmBWBFbA0/oNEm5sW81wldJ6Ez3Qrppl5vvKs8/SUTWaNeFs= X-Received: by 2002:a9f:2e07:: with SMTP id t7-v6mr8031591uaj.54.1530240487878; Thu, 28 Jun 2018 19:48:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 28 Jun 2018 22:47:56 -0400 Message-ID: To: internals@lists.php.net Cc: larry@garfieldtech.com Content-Type: multipart/alternative; boundary="000000000000b37898056fbee00a" Subject: Re: [PHP-DEV] [RFC] User-defined object comparison From: rudolf.theunissen@gmail.com (Rudolf Theunissen) --000000000000b37898056fbee00a Content-Type: text/plain; charset="UTF-8" > > In this case, the order of checking to see what method to call will also > check > for type compatibility. That is, $f < $b checks Foo::__compareTo(), finds > it > doesn't match, and so calls Bar::__compareTo() instead, which does. I'm not sure if I like this, it's a bit non-deterministic isn't it.. that the comparison function called can be determined by the value being compared? While I'm not disregarding this idea entirely, it's another addition we can add at a later stage. It would be a bit of a juggle internally, to hold on to the type error while we attempt the second call, and if that fails, we throw the type error of the first attempt? > > "However, because magic methods aren't inherited" - Wait, they're not? Are > you certain of that? Because 3v4l.org says they are: > https://3v4l.org/P6Hlq Yeah my bad, that was very poorly written, and I'll update it immediately. What I meant to say was that they aren't inherited from any base object class like `equals` is in Java. So if you just have a base class, magic methods aren't inherited from some language-level base class, so you can use whatever parameter and return types you like. I don't understand Future Scope point 1. It... means we're already covering > those operators. Why is there future scope needed? Python, for example, has the ability to override specific comparison operators, such as > > __lt__ for <. Point 1 is trying to say that *if* we want to introduce full, specific operator overloading in the future, we would already have the magic methods for == and <=>. --000000000000b37898056fbee00a--