Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102370 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67913 invoked from network); 22 Jun 2018 13:56:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jun 2018 13:56:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=rudolf.theunissen@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rtheunissen@php.net; sender-id=unknown Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.65 as permitted sender) X-PHP-List-Original-Sender: rudolf.theunissen@gmail.com X-Host-Fingerprint: 209.85.213.65 mail-vk0-f65.google.com Received: from [209.85.213.65] ([209.85.213.65:36736] helo=mail-vk0-f65.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AB/1E-32156-7FFFC2B5 for ; Fri, 22 Jun 2018 09:56:09 -0400 Received: by mail-vk0-f65.google.com with SMTP id o138-v6so3951528vkd.3 for ; Fri, 22 Jun 2018 06:56:07 -0700 (PDT) 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=x/+f4iz1x3PFGAXori5Y+za3pD7X+8rSfYFFlwKIYsw=; b=imnbSPoCCaKfBn/ZE80h4AmFKyM+PscoPJwRl6kvOPxT3A74ovWVyrPsJfaeXXR5in 9vtrqMMhy4Ng2zuUgo8gS9W4mCDVQZiNqePAIb0sNdIlvCEnNuhpVYLjLwXyuo2yV003 SCmlD1LWAQ+KI7GZSQEgu+nKLyEEjFX+h9Gv9maWn19/ZEjBrehcWASPASmB/5SHSlba THu3Bpmry+m8zTNIL/JqJTNnD4uPvkgQz1vhlZvHfZe+Kt2J60ADbCNJJP6BYyO0HFPk tXFjM/DlLN6SSc1RCpfo9N+vJ6P3iZZTpDavjYC2ei0T0KQTBV/dDth5JHdZOQFxwM6Z p65w== X-Gm-Message-State: APt69E1nUHAblye9/GnYF6s4u1eoHYShwYkShv+Qq3pf4k3ECPd+xWvP j+YNeckQg/e2MaaARNh+ReHhQTc1 X-Google-Smtp-Source: ADUXVKI97jqFg3ynM/vjjbuV2DjnRxZIeKi3SJAhIdclHCoLOpyi8+3uPDefMBU6S6ieHDKSQzwEvA== X-Received: by 2002:a1f:60c5:: with SMTP id u188-v6mr1015111vkb.25.1529675765129; Fri, 22 Jun 2018 06:56:05 -0700 (PDT) Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com. [209.85.217.177]) by smtp.gmail.com with ESMTPSA id e190-v6sm2171185vkf.20.2018.06.22.06.56.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 06:56:04 -0700 (PDT) Received: by mail-ua0-f177.google.com with SMTP id k14-v6so4317978uao.12 for ; Fri, 22 Jun 2018 06:56:04 -0700 (PDT) X-Received: by 2002:ab0:7207:: with SMTP id u7-v6mr418931uao.99.1529675764576; Fri, 22 Jun 2018 06:56:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 22 Jun 2018 09:55:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: morrison.levi@gmail.com Cc: danack@basereality.com, internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000091b772056f3b641b" Subject: Re: [PHP-DEV] Equality and relative ordering of objects From: rtheunissen@php.net (Rudi Theunissen) --00000000000091b772056f3b641b Content-Type: text/plain; charset="UTF-8" > > In my opinion we should have functions which take comparator and/or > equality functions as parameters even if we can override these > operators. I really like this idea, because it puts the responsibility of the definition on the caller. It allows you to do things like "Is there an instance of X in this array that has a value of Y greater than Z". This is probably a candidate for a separate proposal though, perhaps even in favour of this one. In saying that, I still believe that there's a place for dynamic comparison and equality if used responsibly. I see the primary value in objects that have a specific, obvious value, such as money or dimensions. On Fri, 22 Jun 2018 at 08:43, Levi Morrison wrote: > On Fri, Jun 22, 2018 at 6:39 AM Levi Morrison wrote: > > > > > > > 1. You can't override the behaviour of `<`, `<=`, `>`, `>=`, `==`, `!=` > > > with a userland implementation. > > > 2. Therefore, you won't be able to affect the internals of array > functions > > > like `in_array`, `sort` etc. > > > > In my opinion we should have functions which take comparator and/or > equality functions as parameters even if we can override these operators. > I'd like to see an outline of such a plan as part of this RFC or as a > precursor to it. > > (I know some already have this option, such as usort, but we don't > have an `in_array` that takes an equality callback, correct?) > --00000000000091b772056f3b641b--